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
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 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.
There have been some fixes that I want to include in the package.
Otherwise I will need to delay those until version 4.2.0, which might
be released next year...
I still support the old calling convention to not break existing code,
but we should move to the new one eventually. This way we can pass the
file type as an argument to not have to calculate it more than once
while calling 'denote-link' and related.
