In earlier commits, `denote-rename-buffer' could open the same file
multiple times when retrieving front matter, as described in
https://github.com/protesilaos/denote/issues/652 .
This occurred because the subroutine `denote--file-with-temp-buffer-subr',
used in the definition of `denote--define-retrieve-front-matter',
contained incorrect conditional logic. As a result, files were reopened
instead of reusing already opened buffers.
Fixes: https://github.com/protesilaos/denote/issues/652
* (denote--file-with-temp-buffer-subr):
When users customize `denote-rename-buffer-function' without checking
whether the current buffer is a Denote buffer, `find-file-hook' may
trigger unintended renames.
Because `denote-rename-buffer' accepts an optional buffer argument, the
Denote buffer check must be performed twice.
* (denote-rename-buffer-rename-function-or-fallback):
This function is extremely slow because calling (dired (cons directory
files)) triggers ls for every file. When there are a large number of
files, The `call-process' becomes expensive. There is no other way to
change this behavior in dired. We should use Emacs’s built-in ls
implementation (ls-lisp). On my machine, with around 200 files, this
reduces execution time by about 6x.
Additionally, prepare-buffer seems unnecessary. It is a private
function (indicated by the double dash) and is not intended for user
access or other use cases. It calls files-fn twice, which is redundant.
We should instead set the revert-function directly in a single function
to make its purpose explicit.
* (denote-sort-dired): refactor
* (denote-sort-dired--prepare-buffer): remove
This was done in pull request 664: <https://github.com/protesilaos/denote/pull/664>.
The change is small, meaning that Alvin does not need to assign
copyright to the Free Software Foundation,
In the DIRNAME list argument to `dired', the first element is treated as a
directory name, with the rest being file paths relative to that directory.
`dired' appears to fall back to the parent directory when DIRED-NAME does not
match any subdirectory, resulting in expected correct behavior; however, when
there is a matched directory, it will attempt to search for files relative to
that directory instead, which may result in file-not-found errors.
Thus, we remove and replace DIRED-NAME such that we always use the directory
that the files are supposed to be relative to.
Fixes: #662
Check what I am doing in denote-fontify-links-mode to make it work
only in some places and to work around the default behaviour of
toggling a minor mode interactively.
This was done in pull request 658: <https://github.com/protesilaos/denote/pull/658>.
The change is small, meaning that alvmts does not need to assign
copyright to the Free Software Foundation.
This patch makes it so only search options in Org links get trimmed when checking whether the linked file exists.
The old regex erroneously truncates filenames containing a single colon, so "/tmp/foo:bar/file.ext" becomes "/tmp/foo".
This was making things too complex for our purposes. Users who need to
do something else should write an advice for this function.
I am also adding an optional DIRECTORIES parameter in the spirit of
commit 5203bc0.
I cannot tell why this is happening. Will need to investigate further.
I thought it might have to do with 'denote-retrieve-filename-title'
changing the match data. But the problem persists even if I put a
regular string in its case which is also found in the completion
candidates I am testing it against.
