Thanks to 82Kang for telling me about the use-case of maintaining
multiple Denote Dired buffers side-by-side. This is done as part of
issue 693: <https://github.com/protesilaos/denote/issues/693>.
I am doing this in response to a question posted by 82Kang in issue
693: <https://github.com/protesilaos/denote/issues/693>.
We already have similar functionality for the denote-grep (and
related) buffers. This is an opportunity for me to also review all
that.
When following links in markdown-mode that are to non-Denote resources
like URLs, you would see the error:
Cannot open ‘nil’ of unknown link type
That is because Denote adds denote-link-markdown-follow to
markdown-follow-link-functions, which eventually calls
denote--act-on-query-link with a nil value.
To solve this, we return nil from denote-link-markdown-follow when we do
not know how to handle the link. That lets markdown-mode try its link
handling. Per the markdown-follow-link-functions documentation, we
should "return non-nil if [we] followed the link, or nil if not."
We use a similar approach in related functions for the Org link
mechanism.
This builds on top of the contribution of Samuel W. Flint in pull
request 683: <https://github.com/protesilaos/denote/pull/683>.
The function insert-buffer is meant to be for interactive use only.
This follows the change made by duli in commit 0f71f12 via pull
request 672: <https://github.com/protesilaos/denote/pull/672>. The
author of the original change has assigned copyright to the Free
Software Foundation.
Also thanks to Jean-Philippe Gagné Guay for reviewing the change and
for reporting a problem with an earlier version of the code in issue
670: <https://github.com/protesilaos/denote/issues/670>.
This follows the change made by duli in commit 0f71f12 via pull
request 672: <https://github.com/protesilaos/denote/pull/672>. The
author of the original change has assigned copyright to the Free
Software Foundation.
Also thanks to Jean-Philippe Gagné Guay for reviewing the change and
for reporting a problem with an earlier version of the code in issue
670: <https://github.com/protesilaos/denote/issues/670>.
This addresses a regression where
'denote-rename-file-using-front-matter' would fail to recognize changes
in an unsaved buffer, or fail entirely if the file had not yet been
created on disk (as described in
https://github.com/protesilaos/denote/pull/670).
The logic now consistently prioritizes the content of an open buffer
over the file on disk. Previously, the code would revert to reading the
file if the buffer was marked as modified; however, since we cannot
reliably detect if a modification affects the front-matter, it is safe
to always use the live buffer state.
* (denote--file-with-temp-buffer-subr): Remove.
(denote--file-with-temp-buffer): Refactor to prioritize buffer content
and remove the dependency on the internal subr.
Fixes: https://github.com/protesilaos/denote/pull/670
Docstring says function returns denote-grep-untitled-string, but it
actually returns denote-query-untitled-string. This commit corrects
the name of the variable in the docstring.
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
