This was done in pull request 728: <https://github.com/protesilaos/denote/pull/728>.
The change is small, meaning that its author does not need to assign
copyright to the Free Software Foundation.
This was done in pull request 723: <https://github.com/protesilaos/denote/pull/723>.
The change is small, meaning that Michael does not need to assign
copyright to the Free Software Foundation.
This was done in pull request 722: <https://github.com/protesilaos/denote/pull/722>.
The change is small, meaning that Jeff does not need to assign
copyright to the Free Software Foundation.
This is based on the code originally written by Jean-Philippe Gagné
Guay in issue 603: <https://github.com/protesilaos/denote/issues/603#issuecomment-2869702877>.
I made stylistic changes to it to make it fit with the rest of denote.el.
I am adding this in response to issue 603 and 718:
- <https://github.com/protesilaos/denote/issues/603> with
participation from Davi Ramos and Jean-Philippe Gagné Guay;
- <https://github.com/protesilaos/denote/issues/718> with
participation from o-rxw and Alan Schmitt.
In implementing this, I am changing my mind that this is purely a
documentation issue. I realised it is better for us to have the main
function in denote.el, so that we can test it better.
This was done in pull request 711: <https://github.com/protesilaos/denote/pull/711>.
The change is small, menaing that Matthieu does not need to assign
copyright to the Free Software Foundation.
Those were sent as part of pull request 708: <https://github.com/protesilaos/denote/pull/708>.
The changes are small, meaning that Marco does not need to assign
copyright to the Free Software Foundation.
denote-{identifier,signature,title,keywords}-regexp used a lazy
zero-or-more capture ([^.]*?), so they matched the bare separator
followed by an extension, e.g. __.js, --.org, ==.org, @@.org. Combined
with denote-file-has-denoted-filename-p, this meant such files were
treated as valid denote notes. lodash's node_modules ships __.js files,
which made a denote-directory containing a lodash checkout enumerate
junk candidates in the file prompt (and previously crash, see preceding
commit).
Switch to a non-empty lazy capture ([^.]+?) so the field must contain at
least one character.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Using denote in a directory that includes files matching '*/__.js'
breaks with "Wrong type argument: stringp, nil" on the file prompt.
lodash ships such files in node_modules, so accidentally pointing
denote at a lodash checkout (or having one under denote-directory)
triggers the error.
These files pass denote-file-has-denoted-filename-p because the empty
keywords section matches denote-keywords-regexp, but they have no
identifier, so denote-file-prompt--format-identifier passed nil to
propertize during affixation. Return nil in that case;
denote-file-prompt-affixate already substitutes "" for a nil prefix.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
I want to reach a point where only denote-dired and related are used.
Maybe this is more appropriate for the next major version, but I can
do it here since this is a new command.
This affects the org-capture specifiers that create a link such as %a
and %l.
Thanks to jarofromel for bringing this matter to my attention in
discussion 702: <https://github.com/protesilaos/denote/discussions/702>.
This was done as part of pull request 697: <https://github.com/protesilaos/denote/pull/697>.
The change is small, repurposing existing code, meaning that the
author does not need to assign copyright to the Free Software Foundation.
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.
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.
This was done in pull request 685: <https://github.com/protesilaos/denote/pull/685>
The change is small, meaning that the author does not need to assign
copyright to the Free Software Foundation.
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 change is small, meaning that Samuel does not need to assign
copyright to the Free Software Foundation.
This change was done in pull request 683: <https://github.com/protesilaos/denote/pull/683>.
This was done in pull request 676: <https://github.com/protesilaos/denote/pull/676>.
The change is small, meaning that gvalson does not need to assign
copyright to the Free Software Foundation.
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
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.
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.
The idea is that if the user has configured denote-directory to a list
of directories, then we want to inform them where the file prompt is
at. For a single directory, this is superfluous.
This was done in pull request 637: <https://github.com/protesilaos/denote/pull/637>.
The change is small, meaning that Yann does not need to assign
copyright to the Free Software Foundation.
We are not using it internally and we do not need to provide it as
part of denote.el. Users who want custom identifiers will eventually
ask for all sorts of variations on this theme. We can keep everything
documented in the manual where we also have the freedom to add more
things to accommodate each use-case.
It is better for helper functions to expect an argument, because then
we can adapt them to our needs. Here we use '(point)', but we may have
another approach elsewhere.
Thanks to Bhargav Kulkarni for reporting the bug in issue 631 and for
Jean-Philippe Gagné Guay for commenting on how best to approach the
problem: <https://github.com/protesilaos/denote/issues/631>.
The 'denote--inside-link-regexp-p' is based on the function
'org-in-regexp' that I found in the org-macs.el file of Org version
9.7.11.
Thanks to Jean-Philippe Gagné Guay for the feedback in issue 631 that
helped refine 'denote--inside-link-regexp-p':
<https://github.com/protesilaos/denote/issues/631#issuecomment-3194420425>.
I have gone back and forth on this issue. Jean-Philippe Gagné Guay
convinced me that it is better to deprecate it because this way the
users will be more informed about what is happening.
This is done in a comment and was then reminded it of it again in pull
request 632:
- <947f0be070>.
- <https://github.com/protesilaos/denote/pull/632>
What I was trying to do earlier with the "maybe prompt" was not a good
idea, as pointed out by Jean-Philippe Gagné Guay:
<947f0be070 (commitcomment-163492171)>.
We do not want to compromise the Lisp calls to the relevant functions:
those should remain non-interactive.
The 'denote-prompts' can be configured to prompt for a directory,
which I forgot worked for parent level directories as well.
About the function 'denote-directory', I have gone back and forth
regarding whether to deprecate it or not. I think it is better to keep
it than have '(car (denote-directories))' everywhere: if we ever need
to change anything, then we can rely on it propagating elsewhere,
including to code that users will likely have.
This way we avoid cases where some other function saves the buffer
before we get to operate on it. One such example is 'lsp-auto-touch-files',
as noted by wuzhihao in issue 627: <https://github.com/protesilaos/denote/issues/627>.
This was done in pull request 625: <https://github.com/protesilaos/denote/pull/626>.
The change affects a single word, meaning that Ashish does not need to
assign copyright to the Free Software Foundation.
This is because the way we handle the check for backlinks is to go
through ALL files. Given the way the denote-rename-buffer-mode works,
we do this EACH TIME we open or create a Denote file. This is inefficient.
The goal is to improve how we handle the retrieval of backlinks.
Though independent of that project, I think a simpler name for buffers
is a better default. Users who need to see an indicator for backlinks
can opt in to it (for example, users may not even be using direct
links, as they rely on query links instead).
Otherwise, we are trying to check if a file anywhere in the file
system has backlinks in the 'denote-directory'. Those links should not
happen, as 'denote:' links only work for identifiers in the 'denote-directory'.
This is discussed with Alan Schmitt in issue 618: <https://github.com/protesilaos/denote/issues/618>.
Alan suggests a keymap to quit the window and kill the buffer. Maybe
we do not need that and can get away with just the special-mode.
This is discussed with Alan Schmitt and Rory Molinari in issue 618:
<https://github.com/protesilaos/denote/issues/618>.
I am using a bespoke buffer because I cannot find a way to achieve the
same result with a call to (dired (cons DIR FILES)). If that is
possible, then I am happy to switch to it. But this will do for the
time being.
Because of lexical-binding, the return value was fixed. But if a user
copies the code into the scratch buffer, renames the function, and
evaluates it, the lambda will be subject to dynamic scoping. This way,
we protect users from a faulty revert-buffer-function.
When we were passing the directory as (dired (cons DIRECTORY FILES))
we were inadvertently setting up Dired to re-use the buffer it
produced. Whereas we always want to have a new one for distinct
searches.
This is how we were doing it in the past but we had issues with the
revert-buffer function. Maybe we are good now.
We want the buffer to revert properly. Files that do not exist anymore
should not inhibit it and subsequent calls to 'denote-sort-dired'
should use their own separate buffer.
This was discussed at length in issue 618 with the participation of
Alan Schmitt and Rory Molinari: <https://github.com/protesilaos/denote/issues/618>.
Bringing them up to speed with what we had for Denote version 4.
Maybe we want to extend them further so that they work with a list
value for denote-directory, but let's keep it like this for the time being.
This way we can, in principle, re-use what we have there.
The original code was contributed by Jean-Philippe Gagné Guay in pull
request 613: <https://github.com/protesilaos/denote/pull/613>.
This is for users who need to customise the behaviour of
'denote-directory-files'. I am adding it in response to issue 5 on the
denote-org repository about the performance of Org dynamic
blocks (where a custom function could help):
<https://github.com/protesilaos/denote-org/issues/5>.
This feature was contributed by Jean-Philippe Gagné Guay in pull
request 609: <https://github.com/protesilaos/denote/pull/609>.
Jean-Philippe has assigned copyright to the Free Software Foundation
and is a long-time contributor to Denote.
The previous design assumed that every file that is linked to will get
an ".html" extension. But this is not correct, such as with PDF files.
Thanks to Morten Kjeldgaard for reporting the bug in issue 614:
<https://github.com/protesilaos/denote/issues/614>.
This build on top of the new feature that allows the user option
'denote-directory' to accept a list of directories. It was contributed
by Jean-Philippe Gagné Guay in pull request 609: <https://github.com/protesilaos/denote/pull/609>.
This builds on top of commit 8e1341d by James Kalyan, which was done
in pull request 597: <https://github.com/protesilaos/denote/pull/597>.
James is in the process of assigning copyright to the Free Software
Foundation.
This builds on top of commit 8e1341d by James Kalyan, which was done
in pull request 597: <https://github.com/protesilaos/denote/pull/597>.
James is in the process of assigning copyright to the Free Software
Foundation.
This builds on top of commit 8e1341d by James Kalyan, which was done
in pull request 597: <https://github.com/protesilaos/denote/pull/597>.
James is in the process of assigning copyright to the Free Software
Foundation.
This approach defines ‘denote-buffer-name-prefix’ as a customizable variable
defaulting to "[D] ".
Then I define ‘denote-buffer-name’ as a function to wrap buffer names in such
that they use ‘denote-buffer-name-prefix’. ‘denote-buffer-name’ also takes the
opportunity to allow designating buffers as "special/temporary" or not which
adds surrounding asterisks.
Lastly, I have wrapped all the Denote-related buffer names with
‘denote-buffer-name’ so commands like ‘denote-sort-dired’, ‘denote-backlinks’,
and ‘denote-grep’ will all use ‘denote-buffer-name-prefix’.
BEFORE MERGING:
- Fix my placement of the definitions inside denote.el. I'm not sure what makes
most sense to you.
- decide on a package-version for the introduction of
‘denote-buffer-name-prefix’. I have it set to "TODO" at the moment.
The 'dired' function cannot be called with a 'cons' whose 'car'
contains a forward slash because that breaks the resulting buffer. By
renaming the buffer after it is created, we circumvent this problem
and can thus use the format we want.
Given this opportunity, the format of the buffer name is subject to a
variable that users can modify. I am doing this in response to pull
request 595 by mjkalyan: <https://github.com/protesilaos/denote/pull/595>.
The functionality to sort query buffers was introduced by Lucas
Quintana in pull request 594: <https://github.com/protesilaos/denote/pull/594>.
Lucas has assigned copyright to the Free Software Foundation.
The functionality to sort query buffers was introduced by Lucas
Quintana in pull request 594: <https://github.com/protesilaos/denote/pull/594>.
Lucas has assigned copyright to the Free Software Foundation.
The functionality to sort query buffers was introduced by Lucas
Quintana in pull request 594: <https://github.com/protesilaos/denote/pull/594>.
Lucas has assigned copyright to the Free Software Foundation.
The functionality to sort query buffers was introduced by Lucas
Quintana in pull request 594: <https://github.com/protesilaos/denote/pull/594>.
Lucas has assigned copyright to the Free Software Foundation.
The functionality to sort query buffers was introduced by Lucas
Quintana in pull request 594: <https://github.com/protesilaos/denote/pull/594>.
Lucas has assigned copyright to the Free Software Foundation.
- Clearing filters and excluding/including files should always replace
current window and reuse buffer name.
- As query buffers are special buffers, they should be enclosed with
asterisks (we already do that for backlink buffers).
This applies to the command 'denote-sort-dired' ('denote-dired'), as
well as the Org dynamic blocks defined in the package denote-org.
Thanks to experimental-code-86 for making the suggestion in issue 572:
<https://github.com/protesilaos/denote/issues/572>.
This was done in pull request 578: <https://github.com/protesilaos/denote/pull/578>.
The change is small, meaning that the author does not need to assign
copyright to the Free Software Foundation.
On Windows, given the `link` as an identifer `"20250312T161853"` , the result of `(denote-link--ol-resolve-link-to-target
link)` is a Windows path `"c:/path/to/the/file.extension"`
However, the result of `(file-exists-p (string-trim-right match ":.*"))` is `nil`, because `(string-trim-right "c:/path/to/the/file.extension" ":.*")` returns `"c"` ,which is the driver letter on Windows.
We can fix it by this: `(string-trim-right "c:/path/to/the/file.extension" ":[^/]+.*")`
These were introduced in commit f70c96c, which was contributed by Lucas
Quintana in pull request 571: <https://github.com/protesilaos/denote/pull/571>.
Lucas has assigned copyright to the Free Software Foundation.
This is how we do it with all our prompts. In practice, it is used in
an interactive spec though it might be used outside of one (also
considering how users may choose to use our functions).
This builds on top of commit f70c96c, which was contributed by Lucas
Quintana in pull request 571: <https://github.com/protesilaos/denote/pull/571>.
Lucas has assigned copyright to the Free Software Foundation.
This is how we do it with all our prompts. In practice, it is used in
an interactive spec though it might be used outside of one (also
considering how users may choose to use our functions).
This builds on top of commit f70c96c, which was contributed by Lucas
Quintana in pull request 571: <https://github.com/protesilaos/denote/pull/571>.
Lucas has assigned copyright to the Free Software Foundation.
This is how we do it with all our prompts. In practice, it is used in
an interactive spec though it might be used outside of one (also
considering how users may choose to use our functions).
This builds on top of commit f70c96c, which was contributed by Lucas
Quintana in pull request 571: <https://github.com/protesilaos/denote/pull/571>.
Lucas has assigned copyright to the Free Software Foundation.
I have not written that node in the manual yet, but I will do it after
I am done editing denote.el.
This builds on top of commit f70c96c, which was contributed by Lucas
Quintana in pull request 571: <https://github.com/protesilaos/denote/pull/571>.
Lucas has assigned copyright to the Free Software Foundation.
I am now using the format suggested by Jean-Philippe Gagné Guay, which
is "denote:TYPE:QUERY". The technical discussion for this is in issue 561:
<https://github.com/protesilaos/denote/issues/561>.
Perhaps there is a way to apply a different face to the query links,
though I do not think this is a critical feature.
What remains to be decided is if we can/should have shorter TYPE
values than the ones I am using now.
This makes it easier to reason about Denote links. The addition of a
link to the heading/context/CUSTOM_ID is better left for those who
want to opt in to the feature.
This way it can be redefined by other packages, such as
'denote-search'. Thanks to Lucas Quintana for asking for this addition
in issue 561: <https://github.com/protesilaos/denote/issues/561>.
I still need to work on the link implementation for file types other
than Org (in 'denote-fontify-links' and related) and then expand the
manual to document all the changes herein. Though I want to make this
commit first to give others the chance to review the code.
This reverts commit c0df642eca.
We will use the approach suggested by Jean-Philippe Gagné Guay in
issue 559, namely, to 'let' bind the denote-directory where we need to
without adding too many parameters to the 'denote-directory-files':
<https://github.com/protesilaos/denote/issues/559>.
This is to support a use-case in 'denote-journal' of setting a path
outside the 'denote-directory', as reported by Kevin McCarthy in issue
1 on the 'denote-journal' repository: <https://github.com/protesilaos/denote-journal/issues/1>.
This was done in pull request 557: <https://github.com/protesilaos/denote/pull/557>.
The change is small, meaning that eum3l does not need to assign
copyright to the Free Software Foundation.
I will update the manual later because I am still working on another
branch that modifies the README.org and I do not want to bother with
a messy conflict resolution.
We deleted it at some point, but did not remove everything. Thanks to
Jean-Philippe Gagné Guay for bringing this matter to my attention in
the discussion about reorganising the Denote code base. Issue 543:
<https://github.com/protesilaos/denote/issues/543>.
This prevents an error when calling 'denote-sequence-split' with an
empty string. In particular, this happens when
'denote-sequence-get-relative' is called with TYPE 'siblings' on a
top-level sequence. 'denote-sequence-get-all-sequences-with-prefix' is
apparently not used in a context where it would receive an empty
sequence, but check for empty sequences there as well for consistency.
The type is passed to 'denote-sequence-get-relative', which uses types
that are slightly different than those in 'denote-sequence-types'. Also
update the error message displayed by 'denote-sequence-get-relative'
when it receives an unrecognized type to reflect that it no longer uses
the types from 'denote-sequence-types'.
Create the new helper function 'denote-sequence--sequence-prefix-p' and
use it in both 'denote-sequence-get-all-files-with-prefix' and
'denote-sequence-get-all-sequences-with-prefix'.
This was done in pull request 540:
<https://github.com/protesilaos/denote/pull/540>. The change is less
than 15 lines, meaning that Kierin does not need to assign copyright
to the Free Software Foundation.
In principle, we should not be doing this for private symbols, but it
helps with transitioning old code to the new normal. We have had this
practice for a long time now (and I eventually remove those warnings a
few releases afterwards).
Thanks to bdillahu for reporting the issue with some sample code in
the manual and to Jean-Philippe Gagné Guay for confirming the problem.
This was done in issue 538: <https://github.com/protesilaos/denote/issues/538>.
This is in response to a question by Alan Schmitt in issue 536:
<https://github.com/protesilaos/denote/issues/536>. Also thanks to
Jean-Philippe Gagné Guay for the comment about whether this is a
useful feature.
The denote-link command already inserts a signature if it is there,
plus we have the denote-link-description-format, which can be set to
whatever style the user prefers. This command I am deprecating was
basically doing what a user gets as soon as they type = in the
minibuffer (which will match files that have a signature).
This way, any other function that needs to derive the file path from
the completion candidates will do it correctly.
I discovered this by discussing with Alan Schmitt an issue involving
the Embark package. This was done in discussion 524:
<https://github.com/protesilaos/denote/discussions/524>.
This is because our 'denote:' links have the same capabilities as the
'file:' links with regard to moving to a specific position in the
buffer.
Thanks to leafarbelm for reporting the bug in issue 523:
<https://github.com/protesilaos/denote/issues/523>.
This patch fixes the regression bug in
`denote-sequence-get-all-files`, as discussed in #526. The core idea
behind this fix is to delete duplicates within the list of files and
buffers in the `denote-directory` matching a certain signature.
Otherwise users may not know why a command that produces a given
sequence does not use the expected number. Thanks to elliottw for
reporting this in issue 519: <https://github.com/protesilaos/denote/issues/519>.
The idea is to support both numeric and alphanumeric sequencing
schemes, as documented in the new user option 'denote-sequence-scheme'.
We now have the tools to correctly split, join, increment, and convert
input accordingly, such that we can, for example, accurately produce a
child of sequence "1a2" (we could already do that for numeric
sequences).
What is covered herein is just the groundwork. I still need to extend
the helper functions which directly support the creation of new
parent, child, or sibling sequences. While this still is a lot of
work, the hard part is now done.
Thanks to Mirko Hernandez for suggesting the creation of "do-what-I-mean"
commands, which I interpret as this sort of thing.
This was done in discussion 506:
<https://github.com/protesilaos/denote/discussions/506>.
Thanks to Mirko Hernandez for suggesting the creation of "do-what-I-mean"
commands, which I interpret as this sort of thing.
This was done in discussion 506:
<https://github.com/protesilaos/denote/discussions/506>.
Part of this is to encapsulate the logic in a single function and also
to use the backward-compatible calling convention of 'sort', as we did
with Claudio Migliorelli in pull request 518:
<https://github.com/protesilaos/denote/pull/518>
This was missing from the original implementation about all these
comparison functions. Thanks to Maikol Solis for adding the new
defcustom in commit 1b65d9e, which was done in pull request 517:
<https://github.com/protesilaos/denote/pull/517>.
As pointed out in #516, the `sort` function seems to have a
mismatching paradigm depending on the Emacs version the code is run
on. However, the `denote-sequence--get-largest` implementation was
simply using the `:in-place` key as third argument, while the original
implementation of `sort` only accepted two arguments, which is not
necessary. The sorting is done in place anyhow. This commit modifies
the `denote-sequence--get-largest` function to be compatible with
older Emacs versions.
The function `denote-sort-dired` wasn't working due to the
`identifier` missing case in `denote-sort-files`. This is useful when
you customize `denote-file-name-components-order`.
I thought about the scenario of generating a descendant, but it does
not seem to make sense workflow-wise. The user should be more
specific, such as to create the child of a sequence.
THIS NEEDS MORE TESTING.
The idea is to find the level at which we are inserting a child, then
figure out which is the largest already there, and increment that
number.
This was done in pull request 505: <https://github.com/protesilaos/denote/pull/505>.
The change is small, meaning that Laurent does not need to assign
copyright to the Free Software Foundation.
1. Do not use 'find-file' to get the buffer of the selected file
because this has the side effect of switching the current window buffer.
2. If the buffer is in a window, select that window to perform the
operation. Otherwise, do the work with its buffer as current and
then display the buffer below the current one.
3. Produce a message to inform the user what happened.
Otherwise, this was making the alias and the alised function do
nothing. Thanks to Olver Epper for reporting a problem with this
command in issue 503: <https://github.com/protesilaos/denote/issues/503>.
Thanks to Alex Griffin for starting the discussion about this feature
and to Jean-Philippe Gagné Guay for contributing to it. It was done in
issue 489: <https://github.com/protesilaos/denote/issues/489>.
Thanks to Samuel Flint for informing me that a nil argument was not
doing the right thing. We want to be more careful in this regard. This
was discussed in issue 490: <https://github.com/protesilaos/denote/issues/490>.
Use denote-file-has-denoted-filename-p function. It does not validate
the location of the file. It validates that the file respects Denote's
file-naming scheme instead of only the presence of an identifier.
We want it to work when the journal files are inside a directory and
we also need it to account for variations of denote-file-name-components-order.
Thanks to Samuel Flint for informing me about the previous
implementation not working inside of a journal subdirectory. This was
done in issue 485: <https://github.com/protesilaos/denote/issues/485>.
This has the benefit of extending support for the 'rx' syntax to the
:not-regexp parameter. In principle, this syntax should be available
for all user-facing regular expressions of the dblocks.
This was contributed by Octavian in pull request 483:
<https://github.com/protesilaos/denote/pull/483>. The change is within
the allowed ~15 line limite, meaning that Octavian does not need to
assign copyright to the Free Software Foundation.
This does not work yet for common actions like renaming the file based
on its front matter. I will continue testing how viable this is and if
it is worth pursuing. I do not want to make the code more complex to
accommodate this use-case, so let's see how it goes.
This was originally contributed by Jean-Philippe Gagné Guay in pull
request 480: <https://github.com/protesilaos/denote/pull/480>. The
idea is to use this regular expression which will 99% not exist in a
file to handle the case where the user does not want to get the value
of the given entry. The alternative would be to rewrite more parts of
the code, so this feels safer and is easier.
This makes it easier to edit the text after calling 'denote-open-or-create' (and related).
We do not want to skip the title prompt completely, because the user
may not necessarily search for a file using a query that is a
perfectly valid title. For example, with the 'orderless' package set
up, they may type "title test" to match "This is a test title".
If one open the parent of denote-directory in Dired and use "i" on the
denote-directory, the notes of this subdirectory will be listed in the current
Dired buffer. The user can mark them and call denote-link-dired-marked-notes.
Previously, this would fail because the current Dired buffer is not in
denote-directory.
Otherwise it kills the buffer too early.
Thanks to hapst3r for reporting this problem and to Jean-Philippe
Gagné Guay for contributing to the discussion about how best to
approach this. Done in issue 460:
<https://github.com/protesilaos/denote/issues/460>.
This was done in pull request 456: <https://github.com/protesilaos/denote/pull/456>.
The change is small, meaning that Aziz does not need to assign
copyright to the Free Software Foundation.
Thanks to Cosmin-Octavian C for providing the sample code in issue
437: <https://github.com/protesilaos/denote/issues/437>. Also thanks
to Samuel Flint for suggesting such a feature and discussing the issue.
This builds on top of commit 126238c by Alan Schmitt, which was done
in pull request 443: <https://github.com/protesilaos/denote/pull/443>.
The change extracts the code we had in a function into a separate
function, though Alan has anyway assigned copyright to the Free
Software Foundation.
This function returns the path to a journal entry with the given date,
or nil if there is none.
Refactored `denote-journal-extras-new-or-existing-entry' and
`denote-journal-extras-link-or-create-entry' to use it.
This way, we do not operate on arbitrary paths. Users can still do
that with custom code, though it is better for us to focus on the
intent of the code.
Now we can add Denote links in those buffers as well. Whereas before
it would not work, as Denote would not recognise the file type.
Thanks to coherentstate for bringing this matter to my attention in
issue 418: <https://github.com/protesilaos/denote/issues/418>.
This makes it consistent with how 'denote-rename-file' works. I am
implementing this in response to issue 401 where Alp Eren Kose assumed
this was the default behaviour: <https://github.com/protesilaos/denote/issues/401>
I think it makes sense to have it this way to avoid such confusion.
Still, it seems easier to edit the file and call 'denote-rename-file-using-front-matter'
directly, rather do an intermediate step through Dired.
This builds on top of the contribution of skissue, which was done in
pull request 398: <https://github.com/protesilaos/denote/pull/398>.
The change is small, meaning that its author does not need to assign
copyright to the Free Software Foundation.
We update this so that users know when the default value was added or
last changed.
These are related to the contribution by Ashton Wiersdorf in pull
request 392: <https://github.com/protesilaos/denote/pull/392>.
This makes it so that denote-rename-buffer--format only searches for
backlinks to the current file if "%b" is part of the format string.
This is because searching for backlinks might be a little expensive,
and it is good to avoid this cost if the user doesn't want it.
This way it works even when the buffer is renamed via the
'denote-rename-buffer-mode'. Thanks to skissue for reporting the
problem and discussing it with me. This was done in issue 393:
<https://github.com/protesilaos/denote/issues/393>.
The change is small, meaning that Jakub does not need to assign
copyright to the Free Software Foundation. This was done as pull
request 395: <https://github.com/protesilaos/denote/pull/395>.
The `denote-journal-extras--entry-today` was misbehaving if keywords were in front of the identifier (which is allowed since denote 3.0.0). The corrected version (1) searches for files only based on date and (2) subsequently filters them for the denote-journal-extras-keyword.
We do this by expanding the lists without using an intermediate
buffer. The previous approach was not working as intended in a silo,
because the dir-local value of 'denote-directory' was not present.
Thanks to yetanotherfossman for reporting the problem with
'denote-add-links' when used in a silo and for figuring out that the
temporary buffer was part of the problem. This was done in issue 386:
<https://github.com/protesilaos/denote/issues/386>.
I had removed it in commit ca79f35, but we seem to still need it for
Markdown's C-c C-o to do the right thing over a 'denote:' link.
This builds on top of the new fontification feature provided by Abdul-Lateef Haji-Ali in
pull request 344 (commit 4d12452): <https://github.com/protesilaos/denote/pull/344>.
We do not need it because Org fontifies 'denote:' links natively.
This builds on top of the new fontification feature provided by Abdul-Lateef Haji-Ali in
pull request 344 (commit 4d12452): <https://github.com/protesilaos/denote/pull/344>.
This includes stylistic changes, but also the inclusion of a more
informative help-echo, as well as the denote-faces-link.
This builds on top of the new fontification feature provided by Abdul-Lateef Haji-Ali in
pull request 344 (commit 4d12452): <https://github.com/protesilaos/denote/pull/344>.
This builds on top of the new fontification feature provided by Abdul-Lateef Haji-Ali in
pull request 344 (commit 4d12452): <https://github.com/protesilaos/denote/pull/344>.
I still need to update the manual accordingly.
The dynamic blocks in a file do not evaluate with C-c C-c as they
should, unless the user explicitly loads the 'denote-org-extras'
feature. Whereas we want this to work automatically.
Thanks to Kolmas for reporting the bug in issue 371:
<https://github.com/protesilaos/denote/issues/371>.
This ensures that we retrieve the correct file name components from
the file name. One such case where this was failing is with the
identification of the default value of the keywords' prompt while
using 'denote-rename-file'.
Thanks to Kolmas for reporting this bug in issue 375:
<https://github.com/protesilaos/denote/issues/375>.
This wouid match the wrong heading if there were no spaces between the
headings. Thanks to kilesduli for bringing this matter to my attention
in issue 354: <https://github.com/protesilaos/denote/issues/354>.
We want the title prompt to do the following:
1. Find the title from the file's front matter.
2. Find the title from the relevant Denote file name component.
3. Fall back to the name of the file UNLESS it already has an
identifier. In this case, the file does not have a Denote title
component, so we do not want to put the rest of the file name (e.g.
identifier plus signature/keywords) as the initial title as that
will duplicate the contents of the file name.
We had this before, but point 3 was failing.
Thanks to Alan Schmitt for bringing this matter to my attention in
discussion 353: <https://github.com/protesilaos/denote/discussions/353>.
We do not want it to return the file-name-base because this will
duplicate the text of the file name when there is no TITLE component,
as demonstrated by duli in issue 347: <https://github.com/protesilaos/denote/issues/347>.
The goal is to decouple file selection from the logic of the "... or
create" commands we have. We want to require a match to a file by
default and to only have a fallback "or create" action in those cases
where it is requested.
The changes I make here apply to the "... or create" commands, though
they also affect 'denote-link' and related. When we prompt to link to
a file, we require a match, such that the user cannot exit the
minibuffer with a string that does not expand to an existing file.
This was an error we were not handling. It was also an easy mistake to
make.
This follows the discussion with Jean-Philippe Gagné Guay and Alan
Schmitt in issue 339: <https://github.com/protesilaos/denote/issues/339>.
Because we do not force a match, we need to check if the user's input
matches a file uniquely. Otherwise we return the input as-is, which is
then used by 'denote-open-or-create' (and related).
To make sure that the latest input is used and to not mess up with the
minibuffer history, we now have a new internal variable that handles
this case.
We do not need to have full file system paths there, nor the user's
raw input. What we want are file names relative to the
denote-directory.
Thanks to Alan Schmitt for noting that the history was not working
properly. This was done in issue 339:
<https://github.com/protesilaos/denote/issues/339>.
This covers the contribution by Alexandre Rousseau in commit 6f1773a.
The change is small, so Alexandre does not need to assign copyright to
the Free Software Foundation.
It does not look right, especially when we show context with Xref. We
better control the name of the buffer, but otherwise limit the
contents to backlinks only.
The built-in `denote-dired-rename-marked-files-with-keywords` function
replaces all the keywords of marked files with user-input keywords.
This is really useful, but my most common use-case is needing to add
a particular keyword or remove a particular keyword from marked notes.
This commit re-arranges the plumbing of
`denote-dired-rename-marked-files-with-keywords` into two internal
functions: `denote-dired-rename-marked-files--change-keywords` and
`denote-keywords--combine`.
This lets us create two new functions --
`denote-dired-rename-marked-files-add-keywords` and
`denote-dired-rename-marked-files-remove-keywords`.
Closes: #315
Thanks to Sven Seebeck for noticing that we did not document this for
the 2.3.0 release. Thanks to Jean-Philippe Gagné Guay for helping me
refine the code. This was all done in issue 298:
<https://github.com/protesilaos/denote/issues/298>.
Thanks to Kristoffer Balintona for discussing with me how
~org-capture~ interfaces with ~org-store-link~. I updated the
documentation accordingly. This was done in issue 267:
<https://github.com/protesilaos/denote/issues/267>.
The function is stable. Others who extend Denote may find it useful.
Thanks to Peter Prevos for starting this effort in pull request 291:
<https://github.com/protesilaos/denote/pull/291>.
This is a case where we do not want to unconditionally remove the
signature when 'denote-prompts' does not include a signature prompt.
Signatures only exist in the file name, not any front matter, so we
want to give the user the chance to decide what to do with an existing
one while renaming the file.
Files without a signature are not affected by this change.
We had removed this in commit ac0c361, thinking it was not necessary,
though Alan Schmitt reported a case where we actually needed this
functionality. This was reported in issue 283:
<https://github.com/protesilaos/denote/issues/283>.
Thanks to Jean-Philippe Gagné Guay for identifying the regression and
for taking the initiative to bring back the feature in pull request
286: <https://github.com/protesilaos/denote/pull/286>. We cannot merge
that one because it includes other in-development snippets.
Other mentions of this are correct, as is the intent expressed in the
code.
Thanks to mentalisttraceur for bringing this matter to my attention in
issue 275: <https://github.com/protesilaos/denote/issues/275>.
It is better to keep what we introduced in a previous version than to
remove it outright. Those who do not find such completion useful can
simply disable it. If there are any issues with the reliability of
history entries, we can assess our options and act accordingly.
This affects every Denote command that prompts for a file (e.g. to
link to it).
Previous versions of Denote had this feature, but it was depending on
a project.el code that did not do exactly what we were expecting.
With Jean-Philippe Gagné Guay we tried to relativise file paths using
display properties, but could not get the completion highlights to
work correctly. This was discussed in pull request 239, with input
from Mark Olson: <https://github.com/protesilaos/denote/pull/239>. A
similar request for relative file names was considered in issue 233
with the participation of Vick (VicZz):
<https://github.com/protesilaos/denote/issues/233>.
We do not want to confuse users with similarly named commands. This
mode is an internal implementation detail. If anyone needs to run
manually, they are probably doing something out-of-the-ordinary, in
which case we can assume they know how to (funcall major-mode).
To reproduce the problem: open a new note and while it is empty, try
to insert and populate an org dblock of type "denote-missing-links".
This leads to the following stack-trace:
```
Debugger entered--Lisp error: (wrong-type-argument stringp 65)
file-name-nondirectory(65)
file-name-extension(65 :period)
denote-get-file-extension(65)
denote-get-file-extension-sans-encryption(65)
denote-filetype-heuristics(65)
denote-link-description-with-signature-and-title(65 nil)
denote--link-get-description(65)
#f(compiled-function (file) #<bytecode -0x3aa12408d80ef11>)(65)
mapc(#f(compiled-function (file) #<bytecode -0x3aa12408d80ef11>) "All links matching ‘reference/2024012’ are present")
denote-link--prepare-links("All links matching ‘reference/2024012’ are present" org nil :no-other-sorting)
denote-link--insert-links("All links matching ‘reference/2024012’ are present" org nil :no-other-sorting)
org-dblock-write:denote-missing-links((:name "denote-missing-links" :regexp "reference/2024012" :indentation-column 0 :content #("\n" 0 1 (org-fold-core-fontified t fontified t))))
```
There are two issues in the underlying code:
1. When `denote-org-extras-dblock--get-missing-links` finds 0
missing-links, it returns with a string (return value of `message`)
instead of with an empty list.
2. When there are 0 pre-existing denote links in the current
buffer, `(denote-link--expand-identifiers
denote-org-link-in-context-regexp)` returns nil. This sets
`linked-files` value to `nil` and short-circuits the `if-let` when it
should not.
This commit fixes these two issues.
The change done in commit e8d4a83 is about the placement of one
parenthesis. The author does not need to assign copyright to the Free
Software Foundation.
We want all commands that rename the file to conform with this use
option. The idea is to have an "expert mode" for those who know what
is happening and do not need to go through any further prompts or
extra steps.
This commit modifies the following functions:
- `denote-type`
- `denote-date`
- `denote-subdirectory`
- `denote-template`
- `denote-signature`
Instead of overwriting the value of `denote-prompts`, this change adds
the specific symbol to the existing value of `denote-prompts`.
We should not be adding the .md suffix because the export mechanism
does not also convert the target file into Markdown format. Instead,
we must preserve the original path.
This is relevant when the 'denote:' link has an optional search
extension to jump to a location (same as with the standard Org 'file:'
link type). Denote uses this facility with the command
'denote-org-extras-link-to-heading', which is part of the new optional
extension 'denote-org-extras.el'.
Thanks to @fingerknight for noting that the search extension for not
part of the exported link anchor. This was done in issue 250:
<https://github.com/protesilaos/denote/issues/250>.
This is in light of the discussion that eventually led to the removal
of the user option denote-user-enforced-denote-directory.
Discussed in issue 244 with the participation of Jean-Philippe Gagné
Guay and Mirko Hernandez: <https://github.com/protesilaos/denote/issues/244>
Done in pull request 246, by Jean-Philippe Gagné Guay:
<https://github.com/protesilaos/denote/pull/246>
Thanks to everyone involved!
This was done in pull request 249:
<https://github.com/protesilaos/denote/pull/249>.
The change is below the ~15 line limit and, as such, the author does
not need to assign copyright to the Free Software Foundation.
- Corrected variable name from `user-enforced-denote-directory` to
`denote-user-enforced-denote-directory`.
- Removed the paragraph that referred to its usage in
`denote-org-extras-extract-org-subtree' function. Apparently, this
function does not use `denote-user-enforced-denote-directory`
variable.
This commit modifies the following functions:
- `denote-type`
- `denote-date`
- `denote-subdirectory`
- `denote-template`
- `denote-signature`
Instead of overwriting the value of `denote-prompts`, this change adds
the specific symbol to the existing value of `denote-prompts`.
This was done in pull request 249:
<https://github.com/protesilaos/denote/pull/249>.
The change is below the ~15 line limit and, as such, the author does
not need to assign copyright to the Free Software Foundation.
- Corrected variable name from `user-enforced-denote-directory` to
`denote-user-enforced-denote-directory`.
- Removed the paragraph that referred to its usage in
`denote-org-extras-extract-org-subtree' function. Apparently, this
function does not use `denote-user-enforced-denote-directory`
variable.
We do not want to limit this to empty strings, because there are cases
we will need to arrange for the return value to be that. Whereas we
get nil for free.
In that scenario, we want to return a literal emptry string. In
practice, this means that when we format the front matter, a nil value
for the title is inserted thus:
---
title: ""
---
Not like this:
---
title: "nil"
---
This change ensures that `denote-org-extras-extract-org-subtree`
behaves similar to the standard denote system when extracting existing
data into denotes.
Closes: #241
This property is automatically added to a task when we mark it as
DONE. If both DATE as well as CREATED are not available, this is a
valuable property to use when determining the date of the new note.
This brings back a feature that was deprecated in version 2.2.0, but
makes changes to it so that (i) it is more limited in scope and (ii)
available as a standalone Org dynamic block.
Thanks to Stephen R. Kifer, Peter Prevos, and Elias Storms for the
discussion which made it clear to me that users do have a need for
such functionality:
<https://lists.sr.ht/~protesilaos/denote/%3C1db2104e-70bd-47f9-a7ed-b8d4bb370a7f%40app.fastmail.com%3E>.
The define-obsolete-variable-alias is producing a warning each time
Emacs runs about how the old symbol's value is copied to the new
symbol. We do not want this.
Thanks to Jean-Philippe Gagné Guay and Jousimies for mentioning this
in issue 224: <https://github.com/protesilaos/denote/issues/224>.
If the buffer-file-name is nil, then we do not want to proceed because
'denote-file-has-identifier-p' will return an error.
This should fix the issue with epub files opened with nov.el, as
reported by arsaber101 in issue 229:
<https://github.com/protesilaos/denote/issues/229>.
We might need it for something I have in the works. The idea is to
define a completion table which instructs the completion user
interface to not do any sorting of its own, while also defining a
completion category.
The change is within the ~15 line limit and so Wesley Harvey does not
need to assign copyright to the Free Software Foundation.
That commit was done in pull request 207 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/207>.
Four file renaming commands may lose spaces (denoted by the "="
in existing filenames) when the user renames the file:
1. denote-rename-file
2. denote-dired-rename-files
3. denote-dired-rename-marked-files-with-keywords
4. denote-rename-file-using-front-matter
This is caused by the function `denote-sluggify-signature`, which
calls (indirectly) `denote--slug-no-punct`, which removes, among
many other characters, all "="s, which represent spaces. These
spaces are thus lost even if the user does not change the
signature.
To remedy this situation, all "="s are turned into spaces before
being sent to `denote--slug-no-punct`, as spaces are not removed
by this function. The function `denote--slug-put-equals` turns
these spaces into "="s at the end of the file-renaming operation.
This is what we do with the title and signature prompts. Thanks to
babusri for pointing out the inconsistency in issue 204 on the GitHub
mirror: <https://github.com/protesilaos/denote/issues/204>.
We do not want to try to rewrite front matter if the given file type has
a nil value for its front matter. Furthermore, we do not want to make
the inclusion of front matter mandatory. Front matter is not a
requirement for Denote, as the file name is our point of reference.
Thanks to Glenna D. for reporting an error produced by
'denote-dired-rename-marked-files-with-keywords' in a scenario where
the front matter would be nil. This was done via a private channel
and the information is shared with permission.
This change means that merely loading denote.el causes :filter,
:visible, :active, :label, :suffix, and :selected forms (or their
aliases) in `denote--menu-contents' to be evaluated.
Currently, `denote--menu-contents' only contains expressions which
call `bound-and-true-p' and `derived-mode-p', so it's unlikely that
enabling the Denote menu bar by default will cause breakages.
If `denote--menu-contents' becomes complex, I suggest reverting this
commit, and then suggesting that users add the following to init.el:
(denote-menu-bar-mode +1)
I've been using Denote with Transient. However, when `denote' is
invoked non-interactively (as through a transient prefix) and no
keywords are specified, the empty string gets passed to `sort', which
is an error.
I've made a file that can be used with the `elpaca-test' macro from
the excellent Elpaca package manager to reproduce the bug. I've added
it as a paste here:
https://paste.sr.ht/~ashton314/66e2fe76478542c745368e82a8eb5c14af38e448
This means that we revert the current Dired buffer even if it is not
part of the 'denote-directory'. We do so because the "rename" commands
we provide can be used everywhere on the filesystem.
Thanks to babusri for bringing this matter to my attention. This was
done in issue 203 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/203>.
I recently refactored the denote-title-prompt to use 'completing-read'
and missed the part of setting the 'denote-title-prompt-current-default'.
This is now restored.
I am also simplifying how we are working with the minibuffer histories
to (i) not pollute the denote--file-history with unrelated strings
and (ii) to not have to deal with 'let' bound values in places where I
would rather not have them.
I delved into this in response to the message sent by Aleksandr
Vityazev on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C87a5qevq8i.fsf%40gmail.com%3E>.
Where there are no files matching the input regex,
`denote-sort-get-directory-files` returns nil. Passing this to `dired`
throws an error:
```
(file-missing "Reading directory" "No such file or directory" ".../denote/Testing Dired")
```
This commit handles the empty case by returning an appropriate error
message.
This is now consistent with the title and signature prompts. We now
give users the power to add/remove components as they see fit. Whereas
before we were insisting on adding back some default value, which made
it impossible to remove some value that was no longer relevant.
All 'denote-retrieve-filename-*' functions now do the same thing,
while the sorting algorithm is refined to account for empty strings.
See commits a44600b, b13d899.
We now return an empty string if no title is present. This makes the
behaviour consistent with 'denote-retrieve-filename-keywords' and
'denote-retrieve-filename-signature'.
The use of 'file-name-base' is now subject to a non-nil optional
argument. This makes it easier for the caller to handle cases as they
see fit.
This means that we cover all our fontification needs with this one
point of entry. It also works for 'denote-sort-dired', which can
include files with their subdirectory component in the same flat
listing (a wonderful feature, made better by the right fontification).
This affects the command 'denote-add-links' as well as the
'denote-links', 'denote-backlinks', 'denote-files' Org dynamic blocks.
The latter three can be inserted at point with these commands:
- 'denote-org-dblock-insert-links'
- 'denote-org-dblock-insert-backlinks'
- 'denote-org-dblock-insert-files'
I am removing the macro because the title sort is a bit different than
the others. This is due to the 'denote-retrieve-filename-title' which
always returns a non-empty string.
[ Same idea as with commit 0063240. ]
We do not expose this feature to the commands we provide. Adding it
here creates inconsistencies, such as, for example, with the
'denote-files' Org dynamic block. I prefer to remove this option than
to see its proliferation.
We do not expose this feature to the commands we provide. Adding it
here creates inconsistencies, such as, for example, with the
'denote-files' Org dynamic block. I prefer to remove this option than
to see its proliferation.
It does not work reliably on my end and has been the source of
confusion as a result. I don't think we can guarantee the correct
behaviour at all times.
We better keep the manual for this, otherwise we will have to maintain
up-to-date documentation in two places. This adds to the development
burden and I prefer to avoid it.
1. The :no-front-matter parameter can now read a number value to
omit that many lines from the top of the file.
2. A new :add-links parameter formats the inserted files as a
typographic list and creates a link to each file.
Based on the bug found in the previous commit, I looked at all the
call-sites for `denote-sluggify-signature` and
`denote-retrieve-filename-signature` and found two other places:
1. `denote-rename-file`: Add check to ensure signature exists when
trying to sluggify it.
2. `denote-rename-file-using-front-matter`: Sluggify the signature
before creating the new file-name.
I hit this bug when I called `M-x
denote-dired-rename-marked-files-with-keywords` on the file at point
in a dired buffer. The stack-trace is as follows:
```
Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
replace-regexp-in-string("[][{}!@#$%^&*()=+'\"?,.|;:~`‘’“”/]*-" "" nil)
denote--slug-no-punct(nil "-")
denote-sluggify-signature(nil)
denote-dired-rename-marked-files-with-keywords()
```
`denote-sluggify-signature` gets a `nil` input which it cannot handle.
This happens because the signature is extracted using
`denote-retrieve-filename-signature`, which can return a `nil` value.
The fix is to only call `denote-sluggify-signature` when we have a
signature to handle.
This change is within the ~15 line limit and thus does not require
copyright assignment to the Free Software Foundation.
It was done in pull request 191 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/191>.
I hit this bug when I called `M-x
denote-change-file-type-and-front-matter` on an Org file with empty
filetags, to convert it to Markdown-YAML format.
This is the front-matter of the original file:
```
#+title: Great Content is the Heart of Audience Building
#+filetags:
#+date: [2023-03-08 Wed 18:51]
#+identifier: 20230308T185100
```
The stack-trace is as follows:
```
Debugger entered--Lisp error: (error "‘’ is not a list")
signal(error ("‘’ is not a list"))
error("`%s' is not a list" "")
denote-sluggify-keywords("")
denote--format-front-matter-keywords("" markdown-yaml)
denote--format-front-matter("Great Content is the Heart of Audience Building" "2023-03-08T18:51:00+05:30" "" "20230308T185100" markdown-yaml)
denote--add-front-matter("/.../20230308T18..." "Great Content is the Heart of Audience Building" "" "20230308T185100" markdown-yaml)
denote-change-file-type-and-front-matter("/.../20230308T18..." markdown-yaml)
```
Following the chain of commands shows that the culprit is the line
```
(denote-retrieve-keywords-value file old-file-type)
```
in `denote-change-file-type-and-front-matter`, which returns an
empty string when the rest of the functions expect a list of strings.
I looked at where `denote-extract-keywords-from-front-matter` is being
used and why the code was originally returning an empty string, and it
looks to me that returning an empty list from it now is the right
thing to do.
The two bugs:
1. The minibuffer history does not work because the project.el function
that was being called checks for an abbreviated file path (like
~/path) whereas we always use absolute file paths (like /home/prot/path).
2. The prompt would ask for confirmation if the file did not exist.
This was creating friction for commands such as 'denote-open-or-create',
'denote-link-or-create', and their variants. I consider this a bug
because we want to have the equivalent of the NO-CONFIRM behaviour
that 'completing-read' gives us.
This change undoes part of what Noboru Ota (nobiot) did in commit
6bb6da0882. From the commit message, the
relevant part is this:
(denote-file-prompt): Refactored
- To use the same completion function as 'project-find-file' does.
- The main benefit is that it can let you search notes under all
sub-directories of 'denote-directory'. The original 'read-file-name'
could only search within only single 'denote-directory'
- Note the impact on commands that use 'denote-file-prompt';
i.e. 'denote-open-or-create', 'denote-link', 'denote-link-or-create',
and 'denote-link-ol-complete'
- One minor annoyance may be that the prompt now requires a confirmation
if the user enters text that does not match any of the candidate and
tries to exit
- 'denote--title-history' is directly updated from the minibuffer
completion function. This eliminates the need for
'denote--push-extracted-title-to-history'. The original used
'file-name-history' as the intermediate storage of titles, which are
not really file names, thus resulted in polluting the history for file
names
What I am doing with this change is to retain the spirit of Noboru's
change with regard to the flat listing of files. I agree that the old
tree-based prompt (per 'read-file-name') was not suitable for our
needs. The "impact" mentioned in the commit above should now no longer
be relevant, given what I wrote about NO-CONFIRM. The "minor
annoyance" is gone for the same reason. The title history has since
been fixed in other commits and also in this one given what I covered
above about abbreviated file paths in the project.el functions.
This means that we can call 'denote-link' while capturing a new note.
Thanks to Peter Smith for reporting the bug in issue 186 on the GitHub
mirror: <https://github.com/protesilaos/denote/issues/186>.
Same idea as with commit bd3ddfb. The 'denote--rename-file-subr',
which I am now removing, was not abstract enough and was thus creating
problems. Thanks to Jean-Philippe Gagné Guay for pointing this out in
issue 182 on the GitHub mirror: <https://github.com/protesilaos/denote/pull/182>.
That abstraction was not good enough and thus makes things more
difficult for us. I am reverting to what we had before. We will see
how best to proceed.
Thanks to Jean-Philippe Gagné Guay for telling me about the drawbacks
of the 'denote--rename-file-subr'. This was done on the GitHub mirror.
The reason is that it requires the buffer to be saved, but we do not
want that after modifying the front matter because we want to give the
user a chance to confirm what happened.
Thanks to Frédéric Willem for reporting the problem in issue 185 on
the GitHub mirror: <https://github.com/protesilaos/denote/issues/185>.
I hit this bug when I did the following:
1. Modify the default `denote-rename-buffer-format` from "%t" to
"%s %t" to display signatures
2. Open a Denote file which did not have a signature.
3. Wonder why the buffer did not show up in buffer-listing functions,
and why undo wouldn't work on it and so on.
The answer is here:
https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Names.html#Buffer-Names
> Buffers that are ephemeral and generally uninteresting to the
> user have names starting with a space, so that the list-buffers
> and buffer-menu commands don't mention them (but if such a
> buffer visits a file, it is mentioned). A name starting with
> space also initially disables recording undo information; see
> Undo.
This commit trims the Buffer Name to ensure that there are no leading
or trailing spaces.
In short, you have to follow some convention that control the letter
casing of individual words to make them readable, while keeping them
part of the same keyword. Using the new user option we provide:
(setq denote-file-name-letter-casing
'((title . downcase)
(signature . downcase)
(keywords . verbatim) ; notice the `verbatim' here
(t . downcase)))
With this in place, typing something like 'camelCase' at the keywords
prompt will insert that as-is and treat as a single keyword.
I am clarifying the documentation here as part of the process of
introducing the new 'denote-file-name-letter-casing' option. I do it
in response to the question raised by Peter Smith in issue 184 on the
GitHub mirror: <https://github.com/protesilaos/denote/issues/184>.
I had a bug report about this for my modus-themes: the Info output of
this file would include the spaces as part of the title. Probably it
was fixed in Org, though I won't take any chances. I don't mind the
absence of alignment spaces in the source file.
I first implemented this in commit 0d855bb. However, it did not work
with the default minibuffer because the SPC key performs
completion (popping up the Completions buffer). So users could not
easily input an arbitrary string for the title/signature. I thus
reverted that commit in 9f692cb.
Stefan Monnier suggested the use of the 'minibuffer-with-setup-hook',
which lets us disable SPC completion for the purposes of these
functions. This is most welcome as the functionality is nice to have.
Stefan's feedback was provided on the emacs-devel mailing list:
<https://lists.gnu.org/archive/html/emacs-devel/2023-10/msg00631.html>.
I am implementing this in response to feedback provided by Suhail
Singh who asked that signatures should behave more like keywords. What
I am doing here is not exactly that because keywords can be many
whereas a signature is one, like a title.
Completion from its own history may not be what we settle on. I am
open to suggestions on how to make this more user friendly. I just
don't want to introduce new user options before knowing exactly what
the needs are.
Suhail's feedback on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C652d82c0.c80a0220.e6282.dc47%40mx.google.com%3E#%3C65380146.c80a0220.4698b.d8c0@mx.google.com%3E>.
The new subroutine function paves the way for a new command that can
perform 'denote-rename-file' over a list of files.
As for 'denote-rename-file', the prompts now use text that better
described what they do. For example, instead of "File title: " the
user reads something like "Rename '/home/prot/Documents/test.txt' with
title: ". Same idea for the keywords prompt.
The new command is meant to be simpler to use and more intuitive in
its design. Its name is now describing what it does, which is to only
prompt for KEYWORDS and rename the marked files accordingly.
The prompt for keywords now displays a more informative message in the
minibuffer, which clearly states that the provided keywords are used
to rename the marked files.
I will provide a new command that will perform interactive renaming of
Dired marked files. That one will ask for title, keywords, and
signature.
This is possible due to the numerous refinements made to the
underlying mechanism that reads buffer or file contents. Interested
parties can refer to the Lisp macro 'denote--file-with-temp-buffer'
and its helper function 'denote--file-with-temp-buffer-1'.
In short: Denote can now correctly read buffer contents as well as
file contents.
We had this before and it was used to omit the current file from the
'denote-link' prompt (i.e. not give users the option to link the file
to itself). We probably lost that when 'denote-all-files' was
introduced, though I believe it was not by design. I am adding it back
in, as I see no obvious downside with this.
We do accept a nil value, as noted in doc string of
'denote-journal-extras-title-format'.
Thanks to TJ Stankus for bringing this matter to my attention. It was
done in issue 176 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/176>.
The 'denote-rename-buffer--get-keywords' is superseded by the
'denote-retrieve-keywords-value-as-string', which I introduced in commit
b17980a. Also check df2c7ee, which makes 'denote-keywords-combine' a
public function.
Remove denote-rename-buffer--common-check and denote-rename-buffer--with-unique-name
Refactor denote-rename-buffer--format and denote-rename-buffer--fallback.
What we ultimately want is to be able to extract data from a buffer,
though the previous version did not handle all cases gracefully. A
problem with that was how it would get the title of the current file
as the description of a link, even though it would correctly point to
the selected link target.
This gives us the opportunity to insert the contents of a Denote
buffer that has not been saved yet, such as those that are generated
right after we invoke the 'denote' command.
These have been around for several months now (or even more than a
year). I assume that interested parties have already gotten the
warnings and switched to the currently supported methods.
This is displayed in the Custom interface on a line below the current
value. Showing the 'format-time-string' can help users determine what
sort of style they want if they opt to supply a custom string.
We used to retrieve the 'file-name-extension' without checking if it
was a composite of the file type extension (e.g. ".org") and an
encryption extension like ".gpg". Accounting for this scenario allows
us to properly support encrypted note files, whose extension is
something like ".org.gpg".
Check the two new public functions, 'denote-get-file-extension' and
'denote-get-file-extension-sans-encryption', for the implementation
details.
Thanks to Jens Östlund for reporting a bug with 'denote-keywords-add'
on an encrypted file, which prompted me to investigate this further.
This was done in issue 172 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/172>.
In short, we had a problem with all operations that needed to retrieve
the file extension when that included an encryption component.
The original was done by Kostas Andreadis as part of pull request 173
on the GitHub mirror: <https://github.com/protesilaos/denote/pull/173>.
The tweaks I am making:
1. Make the function private in case we decide to introduce more
changes to it.
2. Make the doc string consistent with the style of the Denote
code base.
The change is less than 15 lines and thus Kostas does not need to
assign copyright to the Free Software Foundation.
The commit is part of pull request 173 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/173>.
We had a regression when we switched to the project.el prompt whereby
the history was not being updated. Or, at least, it was not updated
while I was using it today. We thus populate the history variable
ourselves, though this may not be necessary. We shall see.
Move journaling functions from the Denote manual into the
`denote-journal-extra.el` file.
We introduce the following:
Variables:
* `denote-journal-extra-directory`: The directory where all your
journal entries will be written.
* `denote-journal-extra-templates`: Some templates to help you get
started with journaling.
Functions:
* `denote-journal-extra--make-journal-directory`: Create the
denote-journal-extra-directory if it does not exist.
* `denote-extras-new-stand-alone-journal-entry`: Create a new journal
entry (as a stand-alone file)
Move the functions of the Denote manual related to creating, opening
or running commands _after specifying a silo_ to this new file.
This commit introduces the following:
Variables:
* `denote-silo-extra-directories`: List of directories which are silos
* `denote-silo-extra-commands-for-silos`: List of common commands we
may want to run in a silo
Functions:
* `denote-silo-extra-pick-silo-then-command`
* `denote-silo-extra-create`
* `denote-silo-extra-open-or-create`
Hi Prot and all in the list.
I'm happy to see that Prot has got his off-grid electricity cabin up.
Hope everything is working as you expect it to, Prot.
Here is a patch. I have got this method from Charles Choi's blog article, "Using
Bookmarks in Emacs like you do in Web Browsers" [1].
[1]:http://yummymelon.com/devnull/using-bookmarks-in-emacs-like-you-do-in-web-browsers.html
– nobiot
>From ec217494621d6d70f28c9c3a1eb1b0539e6e92b7 Mon Sep 17 00:00:00 2001
From: Noboru Ota <me@nobiot.com>
Date: Fri, 15 Sep 2023 09:18:08 +0200
Subject: [PATCH] Move "Denote" menu on menu-bar to the end of global-map after
Tools
This was done in pull request 162 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/162>.
The change is small and does not require copyright assignment to the
Free Software Foundation.
The idea was to make things as simple and unobtrusive as possible,
thus I simply treated the "T" separator in the timestamp as a
delimiter. The effect is noticed in 'denote-dired-mode' and the
default backlinks buffer.
The introduction of a new face, 'denote-faces-time-delimiter', makes
it possible for users to revert to the previous style where the "T"
looks the same as the rest of the identifier. Evaluate this:
(set-face-attribute 'denote-faces-time-delimiter nil :inherit 'denote-faces-date)
The change was discussed in pull request 158 on the GitHub mirror,
with my suggestion to not use 'seq-filter' as it affected the return
value: <https://github.com/protesilaos/denote/pull/158>.
The change is below the 15 line limit, meaning that Adam does have to
assign copyright to the Free Software Foundation.
Before, it was possible for Denote to create duplicate identifiers
while renaming non-Denote files that had the same modification date.
Files can have the same modification date when they are processed by a
program, such as with Git or the 'touch' command.
What Denote now does is check for the presence of the given identifier
and produce a new one that is unique. Depending on the command, the
check is done against the 'denote-directory' or the set of marked
Dired files.
The command 'denote-dired-rename-marked-files' gains a new optional
parameter, which is interactively passed by the double prefix
argument ('C-u C-u' with default key bindings). I am not sure this is
the best interface, as we may prefer to always run the check for
duplicate identifiers. The reason I am doing it this way with the
prefix argument is to avoid an unconditional potentially expensive
operation while renaming a large set of files.
The full context is captured on the mailing list[^1]. In brief, the
problem and proposed solution:
Problem : Function `denote-directory` gives global preference to
`.dir-locals.el` in all contexts, with no way to override
it.
Solution : Allow an override so that users can create appropriate
wrapper functions which work properly in all contexts.
This commit adds a new variable `user-enforced-denote-directory`,
which the end-user can use in their wrapper functions to reliably
control which silo their function should execute in.
This commit also updates the README and modifies the following
functions to demonstrate the use of the variable:
- `my-denote-pick-silo-then-command` (this is the base-case)
- `my-denote-org-extract-subtree` (to cut notes from org files)
The section `Use custom commands to select a silo` contains a small
explanation of the new variable.
[^1]:
https://lists.sr.ht/~protesilaos/denote/%3CCABzEscY9f12VDk64nE9OXDJAZMjsLUT2vrw-es%3D4yO%3Dh6ZJ5wQ%40mail.gmail.com%3E#%3CCABzEscY9f12VDk64nE9OXDJAZMjsLUT2vrw-es=4yO=h6ZJ5wQ@mail.gmail.com%3E
The change pertains to sample code in the manual and is within the 15
line limit for contributions without copyright assignment to the Free
Software Foundation.
The provided function did not work correctly. This commit fixes the
following issues:
1. Fix: Extract tags before deleting the region from the source file.
2. Fix: Use `org-end-of-subtree` to calculate the point we should
delete upto. `org-entry-end-position` ends at the first sub-heading
under the tree, which is not what we want. Instead, we want to cut
the whole subtree.
3. Enhance: Retain the date information available in the subtree. We
look for three common places for this information -- The CREATED or
DATE properties in the PROPERTIES drawer, and the CLOSED cookie at
the element level itself.
If a file extension is not in 'denote-file-types', we have no way of
parsing or finding outgoing links in it. This change checks for the
file extension early on in 'when-let*' block and avoids opening the
file which is a relatively costly operation (and would fail finding
links anyway).
The errors should be reserved for the interactive functions. The
others are for developers.
Thanks to Elias Storms for bringing this matter to my attention:
<694c1517be (commitcomment-112677876)>.
Read the doc string of the commands 'denote-open-or-create' or
'denote-link-or-create' for how this is supposed to work.
In short:
- Invoke the "do or create" command.
- Type something that does not match a file.
- In the following title prompt, hit M-p to bring back the last input.
I realised there was a regression here when I read issue 152 on the
GitHub mirror, which was created by user "ustcpxy":
<https://github.com/protesilaos/denote/issues/152>. The issue is
about skipping the file title prompt.
Wade Mealing reported the issue about the performance of
'directory-files-recursively' in large, nested directories. Graham
Marlow proposed a patch that we discussed and eventually installed.
This took place on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/patches/40384>.
Great suggestions! I'm wondering whether we can completely normalize the
use of directory-files-recursively between the two functions. Is there a
reason for them to be different? In my head, I'd imagine the file search
itself is identical--all that needs to change is the use of seq-remove
depending on whether we want to return files or subdirectories.
I brought in your proposed changes and hoisted the predicate function
so it can be shared among both denote-directory-files and
denote-directory-subdirectories.
Follow-up patch for GitHub issue #135 and this thread on "Issue with
linking non-text files"
<https://lists.sr.ht/~protesilaos/denote/%3C871qm9vagf.fsf%40protesilaos.com%3E#%3C86lejapfp5.fsf@nobiot.com%3E>
This patch addresses two issues:
1) The previous related commit 9ce9a24 does not correctly determine the
file extension for the case when 'denote-file-type' is explicitly defined.
When 'denote-file-type' is not org such as markdown-yaml, its extension
is ".md", not the same as denote-file-type (markdown-yaml)
2) 9ce9a24 does not address the case where you (rather edge one)
(a) do not explicitly define 'denote-file-type' (thus org is
assumed)
(b) you create a denote file other than org
(c) you create a non-denote file(s) with the same ID as (b).
In the patch "or" expression is used so that we can prioritize
'denote-file-type' and org file types, and then as a secondary priority
look at 'denote--extensions'. The sequence within this list is not
explicitly define (I would assume it's the alphabetical order).
Following the Denote file-naming scheme, we use the equals sign to
separate individual words in the SIGNATURE field. Signatures are
anchored by the "==" field separator. For context:
- Titles which are anchroned by the "--" field separator use hyphens.
- Keywords which are anchroned by the "__" field separator use underscores.
Thanks to Alfredo Borrás and Jeremy Friesen for discussiing this issue
on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C2A597B4E-5F18-4D97-9457-B3C859DAA020%40zoho.eu%3E>.
Thanks to Kai von Fintel for doing the same on the GitHub mirror in
issue 147: <https://github.com/protesilaos/denote/issues/147>.
Refer to the GitHub issue #142 at https://github.com/protesilaos/denote/issues/142.
With this patch, if you select a non-denote file type from the
completion when a single ID points to multiple files,
'denote-link-find-file' correctly finds the one you selected from the
completion.
It used to pollute the 'denote--title-history' with file paths,
whereas that one should only hold strings of file titles.
Thanks to Jonathan Sahar for bringing this matter to my attention.
This was done in issue 144 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/144>.
Signatures are an optional extension to Denote's file-naming scheme.
They are arbitrary strings of alphanumerical characters that can be
used to establish sequential relations between files at the level of
their file name (e.g. 1, 1a, 1b, 1b1, 1b2, ...).
Files that have the signature follow this scheme (though read the
documentation of 'denote-prompts' for possible permutations):
DATE==SIGNATURE--TITLE__KEYWORDS.EXTENSION
As a reminder, Denote's default file-naming scheme is:
DATE--TITLE__KEYWORDS.EXTENSION
[ Denote can be used to rename any file, not just to create notes. As
such, the file-naming scheme is a powerful, yet low-tech invention to
facilitate searching and filtering. ]
For the time being, signatures are not added to a file's front matter
and are not shown anywhere else beside the file name. This is done on
purpose to simplify the implementation and make sure we define clear
use-cases for this feature (it is easier to add new functionality than
refactor/break existing one).
Users can create files with signatures either by (i) modifying the
'denote-prompts' user option to affect the standard 'denote' command,
or (ii) by generating such files on demand with the command
'denote-signature' (alias 'denote-create-note-using-signature').
Signatures are treated as quasi-identifiers when renaming files that
include them. This means that they are not touched by Denote. The
user must manually update the signature which, in theory, should not
be done if notes already have a predefined sequence.
Signatures are backward-compatible, meaning that existing users are
not impacted by their inclusion.
The signature extension was discussed at length on the GitHub mirror
in issue 115: <https://github.com/protesilaos/denote/issues/115>.
Thanks to Stefan Thesing, Mirko Hernandez, Noboru Ota (nobiot),
Xiaoxing Hu, nbehrnd, Elias Storms, and 101scholar for helping me
reason about this feature, understand its scope, and prototype its
implementation.
The inclusion of the 'signature' branch into 'main' does not mean that
we are done with the development of this feature. We are simply
making it available to more users while preparing for the release of
version 2.0.0 of Denote.
Watch the video series "Denote as a Zettelkasten" produced by Stefan
Thesing, which makes use of these signatures:
<https://www.thesing-online.de/blog/denote-as-a-zettelkasten>.
Thanks to Stefan Thesing and Mirko Hernández for explaining how this
additional file name component can be used for zettelkasten purposes.
This is discussed in issue 115 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/115>. The design is a
work-in-progress, as we still need to implement the signature at the
level of the front matter.
Reference: https://github.com/protesilaos/denote/issues/135
This patch change function 'denote-get-path-by-id' to allow for the following:
- A single ID points to multiple files with different extensions
- Denote needs to find a single file out of the multiple files
- This is not necessarily a user error (export an Org file to an HTML)
- Denote should let user decide their "primary" file extension
The case the patch is intended to fix goes something like this:
- You have 20230216__mynotes--tag.org.
- You export it to 20230216__mynotes--tag.html.
- Both files are in denote-directory
- This means you have two files with the same ID with different
extensions denote-link-find-file, denote-link-find-backlink, and xref
integration might find the html file INSTEAD OF the .org file
This is because html is earlier in the alphabetical order than
org. Because the function uses seq-find, it will find the .html file
first and returns it.
Thanks to Alan Schmitt for requesting this change:
<https://lists.sr.ht/~protesilaos/denote/%3Cm2ttzgn2wu.fsf%40m4x.org%3E>.
Making the function public give users confidence that (i) we commit to
its current behaviour, (ii) consider it stable, and (iii) will
document any changes to it.
This is for backward compatibility with previous Emacs versions.
I was already planning to incorporate 'compat' as I want to make
Denote available for Emacs 27.1. Though now we need this
compatibility layer for commit 9d048ba. Supporting older Emacs
versions requires some more work, but 'compat' gives us what we need
to make it happen.
Thanks to Alan Schmitt for informing me that
'file-name-parent-directory' is for Emacs 29.1:
<https://lists.sr.ht/~protesilaos/denote/%3C87fsb72nge.fsf%40protesilaos.com%3E#%3Cm2cz68ekng.fsf@eduroam-085c.sophia.inria.fr%3E>
This is its intended purpose. The user was already able to, say,
create 'denote:' links to jpg files but 'denote-get-path-by-id' was
refusing to resolve the path.
Thanks to user relict007 for reporting the problem and discussing it
with me in issue 135 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/135>.
The backlinks buffer will now get the correct path when it is
generated inside a silo. This is related to issue 129 reported by
hapst3r on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/129>.
This change is necessary because .dir-locals do not work for buffers,
so we must get the value from the file that calls 'denote-link-backlinks'.
The commit to include a `:reverse` option introduced a bug: the code
in the `when-let` wasn't executed if reverse was nil. This is fixed by
moving the `plist-get` out of the `when-let` into a separate `let`.
This is related to commit 80d0afd about issue 131 on the GitHub
mirror.[1] If the 'denote-directory' is empty, the file prompt will
now return nil instead of throwing an exception. With this change we
make sure to do the right thing in that scenario.
[1] https://github.com/protesilaos/denote/issues/131
The 'denote-file-prompt' would throw an error before. The correct
behaviour is to proceed to the "Create" phase if the denote-directory
is empty.
Thanks to user drcxd for reporting the bug in issue 131 on the GitHub
mirror and for testing my sample code:
<https://github.com/protesilaos/denote/issues/131>.
I am providing this in response to a request from GitHub user
rbenit68. The discussion took place in issue 127 on the GitHub
mirror, with the participation of Mirko Hernandez:
<https://github.com/protesilaos/denote/issues/127>.
The custom code I provide is the expanded version of an idea put forth
by Mirko, to whom I am thankful.
This is my solution to a request made by Mirko Hernandez on the
possible use of the old Denote file prompt. It is better not to
introduce a user option for this case, nor to keep multiple variants
of the 'denote-file-prompt' in denote.el, as we want to avoid
confusing the users.
Mirko's feedback was provided in issue 121 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/121>.
Denote started with management of thoughts/ideas in Emacs org-mode
and extends to files. Some of the tools initiated by Karl Voit do
offer the addition of time stamps, key words from a controlled
vocabulary, etc on files (e.g., date2name) which may be processed
further (memacs). It is worth to hint to them, as introduced by
this commit, in appreciation of an earlier invite.[1]
[1] https://github.com/protesilaos/denote/issues/117#issuecomment-1354372589
The change Matthew made is within the ~15 line limit. It does not
require assigning copyright to the Free Software Foundation. Matthew
will likely need to do so for any future patches.
This update offers the user a means of maintaining the ability to
create denote links in files within sub-directories of a silo, by
suggesting replacing default-directory with an absolute path.
Thanks to Stefan Thesing for proposing this idea in issue 115 on the
GitHub mirror: <https://github.com/protesilaos/denote/issues/115>.
[ Other people participate in that thread and there will be something
more coming out of it. ]
It was done in pull request 116 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/116>.
The change concerns a single line and thus Thibaut requires no
copyright assignment to the Free Software Foundation.
Before this patch, 'denote-modules' needed to be set like this below:
(setq denote-modules
'((project-find-functions . denote-project-find)
(xref-backend-functions . denote--xref-backend)
(denote-module-ffap-enable . denote-module-ffap-disable)))
It's cumbersome for users. With this patch, the same user option can be set as a list of module names like this:
(setq denote-modules '(project xref ffap))
Default value of 'denote-modules' is currently nil.
As discussed in Mailing list:
https://lists.sr.ht/~protesilaos/denote/%3C86a64ooxyi.fsf%40nobiot.com%3E
A new module concept is now implemented together with global/minor mode.
Briefly, they work this way:
1. Set 'denote-modules' by selecting the modules you wish to use
2. Activate the minor mode globally or locally
3. This then disables the modules previously enabled, and enable the
ones newly set -- if it is the first time after Emacs launch, it will
just enable the modules.
The integration previously available with package and xref are now added
as separate modules. A new one with ffap (find-file-at-point) is also
now added.
* denote.el
(denote-get-relative-path-by-id):
A new function to return relative filename by identifier. Currently used
by the ffap module.
(ffap-next-regexp)(ffap-alist):
'defvar' to placate compilers
(denote-module-ffap-last-enabled)
(denote-module-ffap-disable)
(denote-module-ffap-enable):
Module for ffap, find-file-at-point, and a helper-var
(denote-modules-last-enabled)
(denote-modules-disable)
(denote-modules-enable):
Function pair to enable/disable modules and helper-var selected with
'denote-modules'
(denote-modules-mode):
local minor mode to enable/disable 'denote-modules'
(denote-modules-global-mode):
global minor to enable/disable 'denote-modules'
(denote-modules-set):
Setter function for 'denote-modules'
(denote-modules):
The modules selection to be enabled/disabled
Add ':reverse' as a possible argument for the denote-links Dynamic
block. Via this argument the value of denote-link-add-links-sort can
be set for the block.
Add xref-backend facility for Denote.
To enable this feature, `xref-backend-functions' like this.
(add-hook 'xref-backend-functions #'denote--xref-backend)
This lets users use the standard Xref commands such as
'xref-find-definitions' ("M-." by default) 'xref-find-references' ("M-?"
by default) on an identifier in the body of text. To use this, in a
note in a directory, move your point to an identifier like this and
simply invoke one of these commands. 'find-definition' should take you
to the note that identifier points to. 'find-references' by default
should open up a completion in minibuffer with a list of identifiers and
the one at point should already be selected as the default. Simply
press RET to open a Xref buffer with all references of the identifier.
You can tell xref-references not to prompt by adding the following:
(add-to-list 'xref-prompt-for-identifier #'xref-find-references
:append)
Note that you do not need (1) to use any markup to explicitly indicate
the text string at point is a link or (2) to select a range of text.
Currently this function returns any file that starts with the identifier
passed into it. There are cases where contain derivative files that
have the same name sans extetion as the note (e.g. exported HTML file
for the note, etc.). Now the patch changes the function to check
against these cases and returns only denote notes file.
Currently, the "do-or-create" functions do not show files under a
subdirectory that is symlinked to another directory outside
'denote-directory'. This patch enable Denote to recognize files in
symlinked directories and thus lets users more flexible directory
arrangements.
The main intent of the patch is as follows:
- To simplify the implementations of functions related to backlinks that
rely on the Xref library
- To add minimal implementations to integrate Denote with project.el
This is necessary for simplification of Xref/backlinks mentioned
above.
It has given an opportunity to refactor 'denote-file-prompt' to let
you search notes under all sub-directories of 'denote-directory'. The
original 'read-file-name' could only search within only single
'denote-directory'.
This enhances the following commands: 'denote-open-or-create',
'denote-link', 'denote-link-or-create', and 'denote-link-ol-complete'.
The project.el integration also lets users set something like this
below in their configuration. This way, they can generically use
project.el facilities for Denote such as 'project-find-file' and
'project-find-regexp' without a version management tool (e.g. Git)
(add-hook 'project-find-functions #'denote-project-find)
Following is more detail of changes for each function:
* denote.el
(denote-file-prompt): Refactored
- To use the same completion function as 'project-find-file' does.
- The main benefit is that it can let you search notes under all
sub-directories of 'denote-directory'. The original 'read-file-name'
could only search within only single 'denote-directory'
- Note the impact on commands that use 'denote-file-prompt';
i.e. 'denote-open-or-create', 'denote-link', 'denote-link-or-create',
and 'denote-link-ol-complete'
- One minor annoyance may be that the prompt now requires a confirmation
if the user enters text that does not match any of the candidate and
tries to exit
- 'denote--title-history' is directly updated from the minibuffer
completion function. This eliminates the need for
'denote--push-extracted-title-to-history'. The original used
'file-name-history' as the intermediate storage of titles, which are
not really file names, thus resulted in polluting the history for file
names
(denote--retrieve-xrefs): Removed
- No longer used. It was only used by 'denote--retrieve-process-grep',
which has now been removed.
(denote--retrieve-files-in-xrefs): Refactored
- To take IDENTIFIER as the argument. No change to the returned
values. This is for this function to be compatible with the removal of
'denote--retrieve-xrefs'. Retrieving files do not need to use the
intermediate xref-alist, which is a duplicate of work. This change
lets this function directly retrieve file name (group) from xrefs (not
xref-alist) with using Xref public methods
(denote--retrieve-process-grep): Removed
- No longer used. It was only used by 'denote-link--prepare-backlinks'
to retrieve xref-alist for the purpose of creating the backlinks
buffer. Creation of the backlinks buffer has now been refactored to
get closer to the built-in Xref. See 'denote-link-find-backlink' and
'denote-link--prepare-backlinks'
(denote--push-extracted-title-to-history): Removed
- No longer used. See commit message fro 'denote-file-prompt' above
(denote-open-or-create): Refactored
- To not use 'denote--push-extracted-title-to-history', which has been
removed
(denote-link-find-backlink): Refactored
- To not use 'denote--retrieve-xrefs', which has been removed
(denote-link-or-create): Refactored
- To not use 'denote--push-extracted-title-to-history', which has been
removed
(denote-backlinks-mode): Refactored
- To locally set 'denote-project-find'. This is be compatible with the
new project.el integration. The change is necessary for the backlinks
buffer to correctly revert by identifying the denote project root
(denote-link--prepare-backlinks): Refactored
- To set the correct revert function with using the new way
(denote-link-backlinks): Refactored
- To use 'xref--show-xrefs' to create and show backlinks buffer. The
double-hyphen in the name 'xref--show-xrefs' suggests it is a private
function; however, in the current development branch of Xref, there is
a new public function 'xref-show-xrefs'. It is a wrapper function
with the same arguments used in this patch, thus we are further
aligning Denote with the direction of Xref development
(project-root): (project-files): (denote-project-find): Added
- These are Denote specific implementations of generic functions defined
in project.el and a function for a hook to let Denote use them. This
patch contains many built-in Xref functions, which rely on project.el
to identify the "root" of the project. Denote explicitly defines its
root with 'denote-directory'. These newly created methods and function
connect Denote and project.el generic. This way, users without a
version management tool (e.g. Git) for their notes can benefit from
project.el. See one of such major benefits with 'denote-file-prompt'
and the related Denote commands above.
- This change also let users set something like this below in their
configuration to generically use project.el facilities such as
'project-find-file'.
(add-hook 'project-find-functions #'denote-project-find)
* denote-org-dblock.el
(org-dblock-write:denote-backlinks): Refactored
- To align with the change in 'denote--retrieve-files-in-xrefs' as
above
We narrow the scope of the additional code: it only introduces the Org
Dynamic block functionalities (rather than broader Org-mode
integration).
The file is renamed to denote-org-dblock.el and the commentary
updated. denote-org-extract-subtree is removed.
There are some Org-specific features in denote.el, like the 'denote:'
hyperlink type, which are useful for all Org users. Whereas what we
have in denote-org.el is meant to be explicitly requested with a
'require' call and, thus, is more specialised in its
scope/functionality.
This does not make it any less important. It just makes it easier for
us to organise our code.
We do this to avoid conflicts between the two files. As part of the
current development cycle, denote.el depends on Emacs 28, so this
extension cannot be used with Emacs 27 (at least in principle).
The previous one was omitting all files in subdirectories when the
test would return nil (such as with the default value of the new
denote-excluded-directories-regexp).
Thanks to Elias Storms for reporting the regression on the GitHub
mirror: <https://github.com/protesilaos/denote/pull/112#issuecomment-1304568517>.
Thanks to Graham Marlow for the contribution which was done in pull
request 112 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/112>.
The contribution, with the tweaks made in 95cd9f8, is within the
eligible line count: it does not require copyright assignment to the
Free Software Foundation. Though Graham would need to do the
paperwork for any future patch.
This consolidates all link formatting and link extraction/recognition
in the variable 'denote-file-types'. We now have the ability to
control centrally how file types will behave for all linking commands
and their ancillary functions.
With this and other changes from earlier today (see excerpt of Git log
further below), the 'denote-file-types' provides the means to extend
Denote to support ANY FILE TYPE: how it produces its front matter, the
way to retrieve front matter values, the pattern to format keywords,
link format+extraction/ecognition, et cetera. The doc string of
'denote-file-types' covers all the technicalities.
This is an advanced feature of Denote. It is only intended for
experienced users.
A relevant request for such a feature can be found in issue 86 on the
GitHub mirror: <https://github.com/protesilaos/denote/issues/86>.
I believe I have tested everything, though we have plenty of time
ahead of us to test things before the release of version 1.2.0 of
Denote (tentative target is the end of November).
* * *
Relevant commits:
* 2afd07d 2022-10-30 07:03:58 +0200 Protesilaos Stavrou: Make public all variables for link in context
* a553003 2022-10-30 06:50:27 +0200 Protesilaos Stavrou: Make link format variables public
* 9957eaa 2022-10-30 06:39:04 +0200 Protesilaos Stavrou: Clarify denote-link--format-markdown doc string
* 4c7bfe2 2022-10-30 06:34:53 +0200 Protesilaos Stavrou: Make date format functions public
* dec6367 2022-10-30 06:20:38 +0200 Protesilaos Stavrou: Make denote-file-types read a :date-function
* a93d9f2 2022-10-30 06:22:30 +0200 Protesilaos Stavrou: Clarify denote-file-type doc string
* 14f6919 2022-10-30 05:46:23 +0200 Protesilaos Stavrou: Refine denote-file-types documentation
* a214901 2022-10-30 05:44:23 +0200 Protesilaos Stavrou: Refine how denote-file-type-prompt gets candidates
The end goal is to make this variable the single point of entry to all
file-type-aware operations. This way, expert users can add support
for any file type they want. Depending on how it goes, we may even
make it a user option.
Relevant thread on the GitHub mirror issue 86:
<https://github.com/protesilaos/denote/issues/86>.
The main intent of this change is to remove 'denote-xref--insert-xrefs',
which was meant to be a slight modification to the built-in function
'xref--insert-xrefs'. This way, it is intended that future maintenance
work for Denote will be lighter and more in line with the changes to the
built-in Xref library.
Additionally, refactoring is done for 'denote--retrieve-xrefs'. The
intent was to fulfill requirements (A) (B) and (1) (2) described below
in a way that avoids duplication of work -- an attempt to follow the DRY
(Don't Repeat Yourself) principle.
The function name 'denote--retrieve-xrefs' indicates that it should be
generic that should return all the xrefs as retrieved by the Xref
function (A); however, the current usage is only to retrieve backlinks
for a specific file, by excluding a relevant element from the xref-alist
(B). This is used by two different commands: (1) 'denote-link-backlinks'
and (2) 'denote-link-find-backlink'; they have different requirements
for the output format: (1) requires relative file names and (2) requires
an absolute file names.
There can be possibly further refactoring. That is now left to future iteration.
More detail of change to each altered function follows.
* denote.el
(denote--retrieve-xrefs): Add an optional argument FILE. It is meant to
cater to the different requirements of (A) and (B) above.
(denote--retrieve-process-grep): This function is now used only by
'denote-link-backlinks' and refactored to transform GROUP from absolute
file name to relative one for `denote-directory`. This is requirement
(1) above for display purposes of the backlinks' buffer As the doc
string of 'xref--insert-xrefs' notes that GROUP in xref-alist is for
"decoration purposes" and it is also processed in the same way in
'xref--analyze', this should not be a problem.
(denote-link-find-backlink): Refactor to avoid function
'(denote--retrieve-process-grep)' to retrieve xref-alist for requirement
(2) above.
(denote-link--prepare-backlinks): Refactor to use 'xref--insert-xrefs'
directly. As GROUP in xref-alist (GROUP is its key) now carries relative
file name for display purposes, the original logic to insert a list of
file names is also refactored to remove the duplicate work of function
'denote-get-file-name-relative-to-denote-directory'. It is now done
centrally in 'denote--retrieve-process-grep' for the purpose of
backlinks' buffer (with or without the context).
(denote-xref--insert-xrefs): Remove this function completely.
Emacs 27 lacks certain Xref facilities that we need for the
backlinking facility. It also adds to the maintenance burden.
With the help of Noboru Ota, we realised that Denote was broken on
Emacs 27 for quite a while.[1] The fact that we received no feedback
about it suggests that this change is the best course of action going
forward.
[1] <https://lists.sr.ht/~protesilaos/denote/%3C86r0yvzm12.fsf%40nobiot.com%3E#%3C86sfja78ik.fsf@nobiot.com%3E>
This consolidates all the recent changes.
Read the discussion on the mailing list about the refactoring of the
backlinks' buffer, with the participation of Noboru Ota:
<https://lists.sr.ht/~protesilaos/denote/%3C86r0yvzm12.fsf%40nobiot.com%3E>.
Also check the recent commit log for the relevant changes, including
patches from Noboru.
With the denote-backlinks-show-context, we now have two types of
backlinks' buffer: (1) a generic one that uses buttons that we create
and (2) the familiar Xref buffer. These commands are meant to
accommodate both types.
Read the discussion on the mailing list about the refactoring of the
backlinks' buffer, with the participation of Noboru Ota:
<https://lists.sr.ht/~protesilaos/denote/%3C86r0yvzm12.fsf%40nobiot.com%3E>.
Also check the recent commit log for the relevant changes, including
patches from Noboru.
It will confuse users now that we have another option for displaying
the context of links. It is better to just handle this internally.
Furthermore, our fontification does not look nice when the context is
shown. In that case, the standard Xref style looks better because
it (i) clearly distinguishes file names from the context, (2) line
numbers from the context, and (3) highlights the matching identifier
on the given line.
Read the discussion on the mailing list about the refactoring of the
backlinks' buffer, with the participation of Noboru Ota:
<https://lists.sr.ht/~protesilaos/denote/%3C86r0yvzm12.fsf%40nobiot.com%3E>.
Also check the recent commit log for the relevant changes, including
patches from Noboru.
* denote.el
(denote-backlilnks-show-context): Add an user option to toggle the
context.
(denote-link--prepare-backlinks): Add the original insertion logic back
in with refactoring for the xrefs-alist instead of a list of files.
Commit fcefc1d broke 'denote-link-find-backlink' as
'denote--retrieve-process-grep' was refactored to retrieve xrefs-alist.
This change fixes that.
* denote.el
(denote--retrieve-files-in-xrefs): Revert commit 3b9bc00
(denote-link-find-backlink): Refactor to work as expected as before
fcefc1d
The intention of the changes below is to display context of identifier
in the files in the backlinks buffer. Currently Denote's backlinks
buffer display a list of filenames. Denote currently retrieves
xref-items (xrefs-alist) and then strips off the context information and
utilizes only the file name (group) for backlinks buffer. We can utilize
the xref-items as retrieved and make use of the xref's built-in facility
to display the context each identifier is in. This also lets the
backlinks buffer display multiple occurrences of the same identifier in a
single file (as treated by Xref).
* denote.el
(denote--retrieve-files-in-xrefs): Currently unused;
commented out. If sorting of the xref-groups (filenames) is critical,
we will need to first look into xrefs-alist and check if it is not
already done as desired by Xref. If not, will need to consider a
different way to sort xrefs-alist.
(denote--retrieve-process-grep): Changed to return xrefs-alist as
retrieved by 'denote--retrieve-xrefs'. The file name of the current
buffer where 'denote-link-backlinks' is called from is deleted so that
only backlinks appear.
(denote-backlinks-mode-map): Buttons no longer used. Navigation is done
in the same way as Xref. Key "g" is redefined to call 'revert-buffer'
instead of 'xref-revert-buffer'.
(denote-backlinks-mode): The major mode is now derived from
'xref--xref-buffer-mode', which itself is derived from 'special-mode'.
(denote-link--prepare-backlinks): Instead of importing files, this function now works off xrefs-alist. The alist
includes the filename and other information, including "summary" -- the line the identifier is included. Summary may
be available only Emacs 28.1 and onward (refer to function 'xref-item-summary'). As Denote currently supports 27.2,
this may require some way to work around it. 27.2 has not been tested.
(denote-xref--insert-xrefs): This function is a slightly modified
version of the built-in function 'xref--insert-xrefs'. The only change
is the use of function
'denote-get-file-name-relative-to-denote-directory' for the file name
(group in xref).
(denote-link-backlinks): Replace "files" with "xrefs-alist" to make
explicit the data type that is meant to be used in line with all the
other changes above. In addition, 'xref--push-markers' is called so that
'xref-quit-and-pop-marker-stack' (bound to "M-," by default) will work.
This can display the note's buffer where 'denote-link-backlinks' was
called from.
I am implementing this functionality in response to a request made by
Guo Yong: <https://lists.sr.ht/~protesilaos/denote/%3CNF6pFBq--3-9%40tutanota.com%3E>.
The idea is to enhance the "link or create+link" functionality so that
when the user searches for a file that does not exit, they can re-use
the search terms they used initially.
As I explained on the mailing list:
A non-intrusive way of addressing this issue is to leverage the
minibuffer histories. This allows us to type 'M-p' (the command is
'previous-history-element') at Denote's title prompt and get the last
input. The diff further below makes this possible, but I am also
copying the code for your convenience.
Some notes before you check the code:
1. We should not hardcode prompts, such as for file and keywords because
that will contradict the user option 'denote-prompts'. Concretely, a
user may want to create+link to a note that has a specific date, is
in a given subdirectory, and starts with a certain template.
2. The input we provide at the standard file prompt should not be taken
literally. The reason is that it is common for a user to rely on the
completion style to narrow the list of candidates. They are not
necessarily typing the exact title they would like. For example, I
use the 'orderless' package (among built-in options) and will often
type searches out-of-order like "_journal test this" which would
match a file that is "20221024T062254--this-is-a-test__journal.txt".
By adding the last search to the minibuffer history, we let the user
edit the title before they submit it.
Thanks to Guo Yong for testing my prototype and confirming it does
what we need.
If dired-vc-rename-file is set to t, renaming a file under version
control with Denote in a Dired buffer will rename the file using
version control (e.g. "git mv")
The idea is an empty "keywords" entry in the front matter should mean
that the "__KEYWORDS" component of the title should not be present.
We already allow this, such as if the 'denote-prompts' is configured
to not have a 'keywords' prompt (check its doc string).
THIS NEEDS MORE TESTING TO BE SURE THERE ARE NO REGRESSIONS.
This reverts commit cfd2d42954.
I thought it only affected the HTML output, but it also applies to the
Info manual. Given that the indices are for the latter, this change
has to be reverted. Maybe there is way to limit this effect to the
HTML output only.
Currently the HTML version of the manual at
https://protesilaos.com/emacs/denote lists in its table of contents
links to the Indices header and its subheaders, but these are not
present in the HTML version of the manual.
Set the UNNUMBERED property of the Indices header to "notoc" to
exclude the entire subtree from the ToC during export to HTML.
We do not want to grep the contents of, say, video files as this (i)
will not return the expected result, while (ii) will considerably slow
down the collection of backlinks.
Thanks to Charanjit Singh for the contribution, which was done in pull
request 110 on GitHub following our discussion:
<https://github.com/protesilaos/denote/pull/110>.
This, together with Charanjit's other contribution in commits b350035,
fe66333 is within the limits of what is allowed without assigning
copyright to the Free Software Foundation. Though the author will
need to do the paperwork for any future contributions.
If user has whitespace-only region active when inserting a denote-link, behave
org-mode does when inserting a link in this case. i.e selected region is
deleted, and an id-only link is inserted. Active region is trimmed regardless,
so if user try to link "hello " part of "hello world", the text is changed to
"helloworld" with "hello" being the link description and "world" plain text.
This is for commits b350035, fe66333 which were done as part of pull
request 109 on the GitHub mirror: <https://github.com/protesilaos/denote/pull/109>.
The change is within the ~15 line limit and thus requires no copyright
assignment to the Free Software Foundation.
Clearer responsibilities for denote-link--format-link and denote-link.
`denote-link--format-link` has been expanded to accept an optional DESCRIPTION
argument.
It is a common use-case to create a link in existing notes. In such cases, some
text is already there, and user just want to create a link on that text (instead
of inserting the link's title). With this change, if a region is active when
user tries to insert a link, the region is replaced with the link while using
the region's content as link's title.
To rename a file, denote-rename-file-using-front-matter asks for
confirmation via a y-or-n-p. With the optional argument AUTO-CONFIRM,
it's possible to skip these confirmation requests.
We had this for version 0.5.0 which introduced a breaking change to
how keywords are recorded in the front matter. It is unlikely that
someone now uses a version from before that switch happened.
The 'denote-file-types' is, for the time being, specified as a
'defvar' for advanced users. We do eventually want to turn it into a
defcustom, assuming there is a need for it (we will figure it out
through further testing).
This change allows the ':front-matter' property to accept a nil value,
which we internally read as an empty string.
Thanks to Noboru Ota (nobiot) for pointing this out on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C86k05gsqsg.fsf%40nobiot.com%3E>.
This will allow changing front-matter variables by 'setq' after
'denote' is loaded/compiled without needing to set 'define-file-types'
again.
Currently, changing variables 'denote-*-front-matter' to personalize
the front matter with using 'setq' requires the user to set variable
'denote-file-types' again to reflect the change.
This is because 'denote-file-types' is defined with macro expansion
with using the backquote ("`") and "," to evaluate variables
'denote-*-front-matter' inside the macro. This results in the front
matters fixed by the values of front-matter variables at the time of
loading or compiling 'denote', and setting the front-matter variables
thereafter with 'setq' will not affect the front matter in notes
created -- this will require setting 'denote-file-types' again.
For the relevant discussion, read:
<https://lists.sr.ht/~protesilaos/denote/%3C86k05gsqsg.fsf%40nobiot.com%3E>.
Those are not real errors. Just no results from an otherwise valid
search.
This is done in consultation with Elias Storms,[1] who contributed the
'denote-link-add-missing-links' command (see commits faa7a66, 6bf916b).
[1] <2c7184352f>
Elias is in the process of finalising the copyright assignment to the
Free Software Foundation.
Elias' contribution was done in pull request 108 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/108>.
Introduced by 3f47374.
`org-link-store` functions should return `nil` when not
handling the current buffer but the current code always
returns `org-store-link-plist`.
We simply move a parenthesis so that when the `when-let*` aborts
we return `nil`, which was the previous behaviour.
It leads to performance issues in Org under certain circumstances.
Fundamentally, this has to do with the fontification mechanism, which
would call the 'denote-link-ol-face' function too often.
Thanks to Peter Prevos for reporting the issue and discussing it with
me: <https://lists.sr.ht/~protesilaos/denote/%3C87k05umyyo.fsf%40prevos.net%3E>.
It is easier for the maintenance of the project to have such code in the
manual. Otherwise we are setting a precedent where we need to maintain
variants of the same command that have a slightly different behaviour.
Perhaps we will find a more elegant solution that gives the user maximum
flexibility.
This is discussed on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C87fsgvddny.fsf%40protesilaos.com%3E>.
- `denote-link-or-create-with-date' is identical to
`denote-link-or-create' with a date prompt in case of creation
- `denote-open-or-create' opens a denote file if it exists, otherwise it
proposes to create it
- `denote-open-or-create-with-date' is identical to
`denote-open-or-create' with a date prompt in case of creation
Thanks to Sven Seebeck for suggesting the idea and for testing my
prototypes (this information is shared with permission, as it was
provided via a private channel).
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
This way we only try to use the correct face when we are inside of a
Denote note. We do not want Org to try to figure this out in other
situations, such as while building the agenda.
Thanks to Alan Schmitt for reporting the problem on the mailing list.
It led me down the path of debugging the issue:
<https://lists.sr.ht/~protesilaos/denote/%3C877d2e2ini.fsf%40m4x.org%3E>.
This is not necessarily its final state. It may be better to use
subheadings. I will check. The list of functions/variables is not
complete yet. It will be in time for version 1.0.0.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
We are working towards version 1.0.0. The idea is to provide functions
that users/developers can rely on. By making them public (removing the
double hyphens) we signify that those forms are (i) in a stable
state, and (ii) any change to them will be handled with care and
documented accordingly.
This is not part of denote.el, though we provide it in the manual for
users that may need it.
Thanks to sundar bp for suggesting the idea (this was done via a private
channel and the information is shared with permission).
Thanks to user sienic for suggesting the idea and for testing the
prototypes. And thanks to Juanjo Presa for participating in the
discussion to share the view that this functionality should be part of
denote.el. This happened in issue 96 over at the GitHub mirror:
<https://github.com/protesilaos/denote/issues/96>.
This makes it work as intended when 'buffer-file-name' returns the value
of an unsaved buffer. The denote--retrieve-filename-identifier should
have no opinion about whether the file is saved or not. It just needs
to return the identifier.
This is the same idea as with commit c294eaf.
It means that users or developers can rely on this function in their own
code. By making it "public" (removing the double hyphens), we declare
that we will keep this form in check and document any changes to its
behaviour.
This means that users or developers can rely on this function in their
own code. By making it "public" (removing the double hyphens), we
declare that we will keep this form in check and document any changes to
its behaviour.
The current code works even if the link is stored in a file outside the
'denote-directory'. It works for as long as the target file is in the
'denote-directory'.
I discovered this problem while exchanging views with Marc Fargas
regarding commit dd086b7:
<https://lists.sr.ht/~protesilaos/denote/patches/35137>.
Hi,
Denote, uses the `denote:` link type internally.
This patch adds support for `org-store-link` of denote files meaning
that you can call `org-store-link` from a note and get a `denote:` link
instead of the current `file:` link.
The main benefit of a denote link is that it is resilient to renames,
etc. A file link would brake if the note was ever to be renamed.
As a side benefit, as `org-capture` uses `org-store-link` now you can
capture tasks on notes with resilient links!
This may seem related to `denote-link-use-org-id` though that one would
only work with orgmode notes (and, I think, as long as those were
withing `org-directory` when using `id:` links).
This should work with notes in any format, now `org-capture` works and
`org-store-link` too.
Best,
Marc
PS: This closes#104 on Github[1].
PSS: Second attempt at submitting a patch via git-email ...
[1]: https://github.com/protesilaos/denote/issues/104
Signed-off-by: Marc Fargas <marc@marcfargas.com>
Facilitate a slightly smoother note taking by passing the contents of
the region from the denote command to denote--title-prompt as the
DEFAULT-TITLE argument, when the region is active.
The idea behind this DWIM-flavored patch is to be able to take a note
about a subject that appears in a buffer by simply marking it before
invoking the denote command, which feels natural to me.
denote--filetype-heuristics should always return an md filetype if the
file extension is md even if no key regexps match in the file. In that
case, we use the first md type in denote-file-types.
markdown-yaml should appear before markdown-toml in denote-file-types
because it used to be the default markdown type of
denote--filetype-heuristics.
This is for the patches that Abin Simon sent on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/patches/34632>.
The aggregate change is below the ~15 line threshold and thus requires
no copyright assignment to the Free Software Foundation.
The idea is to be able to create a 'denote:' link to any file that has a
Denote identifier and is in the 'denote-directory'.
There still are some refinements to be made, though they belong to
separate commits.
Thanks to Peter Prevos for discussing this on the mailing list:
<https://lists.sr.ht/~protesilaos/denote/%3C87fsi1m5ze.fsf@prevos.net%3E>.
- Use the new functions instead of
denote--retrieve-title-front-matter-key-regexp and
denote--retrieve-keywords-front-matter-key-regexp.
- Add file-type parameters in some functions.
- Refactor denote--filetype-heuristics to not use the retrieval
functions because they depend on the file type and this is what we want
to find in denote--filetype-heuristics.
As descriped in denote-file-type docstring:
By default (a nil value), the file type is that of Org mode.
Any other non-nil value is the same as the default."
See commits 5c2237e and e711b16. This is about updating the front
matter of Org and YAML to the correct syntax for tags.
The function I just wrote is not the best code ever written, but we will
not keep it for too long, anyway.
This is due to the changes we made to the format of the YAML front
matter where tags are now written as a standard comma-separated list of
strings (per commit cb9af65).
Same idea as with commit 5c2237e.
* denote.el (denote-backlink-mode-map): Add new map for 'denote-backlink-mode'.
(denote-backlink-mode): Add new mode that derives from 'special-mode'.
(denote-link--prepare-backlinks): Use 'denote-backlink-mode'.
This is normally used by packages which are built into Emacs and which
specify the :version (e.g. the modus-themes). Though I find it useful
for our purposes as well, as it provides a hint to the user of when the
variable was last updated.
The idea is to try to catch faulty syntax in order to always return the
desired list of strings that Denote uses.
This change was discussed with Jean-Philippe Gagné Guay in issue 74 on
the GitHub mirror, starting from this message:
<https://github.com/protesilaos/denote/issues/74#issuecomment-1206328912>.
Colin McLear's contribution is below the ~15 line threshold and thus
does not require copyright assignment to the Free Software Foundation.
This was done in pull request 70 over at the GitHub mirror:
<https://github.com/protesilaos/denote/pull/70>.
[ Colin is the author/maintainer of the 'consult-notes' package. ]
- Rework denote-dired-rename-marked-files to make it add a front
matter when appropriate.
- Make denote-dired-rename-marked-files-and-add-front-matters
obsolete.
This is an attempt to address our TODO item on the matter. Right now we
insert filetags separated by two spaces, though the Org manual only
shows tags that are separated by the colon sign. Perhaps we should do
the same in Denote to avoid possible confusion.
All those are internal changes that should not concern the user. This
is a continuation of the work done in commit b284da5 by Jean-Philippe
Gagné Guay, which was submitted in pull request 66 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/66>.
The previous one did not execute the form but would instead bind
'denote--only-note-p' as a variable with a value of 'file'.
Writing it this way is the same as:
(when (denote--only-note-p file) (let ...))
This should avoid false positives by anchoring the search at the
relevant front matter key.
The code is broken into smaller parts for easier hacking.
This change should address the bug with false positives reported by
hpgisler in issue 63 on the GitHub mirror:
<https://github.com/protesilaos/denote/issues/63>.
We are already 'require'ing seq, so we might as well use it in the few
cases where we now call functionality from cl-lib.
Thanks to Philip Kaludercic for pointing this out on the emacs-devel
mailing list: <https://lists.gnu.org/archive/html/emacs-devel/2022-07/msg00838.html>.
This is to be sure that Emacs 28 evaluates 'when-let*'. Otherwise we
will end up with errors such as the one reported by hpgisler in issue 62
on the GitHub mirror: <https://github.com/protesilaos/denote/issues/62>.
It should now update only the title and keywords, without erasing the
whole block and replacing it with a new one.
The old method involved (i) duplication of code and (ii) would overwrite
custom front matter that the user would maintain in their file.
The new method should be technically better as well as address the
latter problem.
Thanks to Peter Prevos for the feedback in issue 60 over at the GitHub
mirror: <https://github.com/protesilaos/denote/issues/60>.
A few doc strings put \\ in front of a single quote, but that doesn't
protect the quote from being processed according to
text-quoting-style. Use \\= instead to ensure that the apostrophe is
rendered as is.
It would not use the correct file type extension for the file path, even
though the correct front matter was picked.
The regression was caused by the refactoring in commit a80ffc1. For a
discussion, see pull request 55 on the GitHub mirror:
<https://github.com/protesilaos/denote/pull/55>.
Bring everything up to date and clarify relevant points.
NOTE that I kept the symbol 'denote-dired-rename-file' instead of
replacing it with 'denote-dired-rename-file-and-rewrite-front-matter'.
The obsoletion was done in pull request 51 over at the GitHub mirror but
I found the longer name harder to differentiate from the command
'denote-dired-rename-file-and-add-front-matter' (which is appropriately
named): <https://github.com/protesilaos/denote/pull/51>.
* Add subsections to make it easier to find information.
* Document 'denote-link-dired-marked-notes'.
* Clarify that links are only to what we count as "notes".
The idea is to turn 2020-01-15 into 2020-01-15 16:19 so that the hour
and minute component is not left to 00:00.
This reduces the burden on the user who would otherwise need to input
that value in order to avoid the error of duplicate identifiers.
It also addresses a difference between Emacs 28 and Emacs 29 where the
former does not read dates without a time component.
Thanks to Peter Prevos for the feedback in issue 58 over at the GitHub
mirror: <https://github.com/protesilaos/denote/issues/58>.
This is to allow users to omit non-ascii characters from file names.
Thanks to pRot0ta1p for the feedback in issue 57 over at the GitHub
mirror: <https://github.com/protesilaos/denote/issues/57>.
Example based on the input of pRot0ta1p:
(setq denote-punctuation-excluded-extra-regexp
"[『』〖〗{}「」【】〔〕[]()《》〈〉«»!#¥%…&"'*,。;:、?—]*")
Neither SourceHut nor GitHub/GitLab are compliant with the Org markup.
SourceHut will not render the file at all, while the others render it
but do not parse it properly.
This is another attempt at a change I made earlier today but reverted
soon thereafter (commit 75d63e, reverted by f279395). The previous
implementation would break the interactive usage of 'denote'.
David Wilson (System Crafters channel) spotted the error on the latest
live stream whose main topic was about Denote (thanks, by the way!):
<https://www.youtube.com/watch?v=QcRY_rsX0yY>.
Thanks to Taoufik for the contribution on pull request 50 on the GitHub
mirror: <https://github.com/protesilaos/denote/pull/50>.
The change is below the ~15 line threshold and thus requires no
copyright assignment to the Free Software Foundation.
This should load the setup only after Org is made available. Whereas
what we had before would throw an error if the user was not already
using Org.
Thanks to Abin Simon for reporting the problem and for showing how
Elfeed handles this issue. This was done in issue 47 on the GitHub
mirror: <https://github.com/protesilaos/denote/issues/47>.
They now reflect what is covered in their respective doc strings.
Thanks to Jean-Philippe Gagné Guay for the feedback in issue 41 over at
the GitHub mirror: <https://github.com/protesilaos/denote/issues/41>.
We changed the 'denote' command to always expect a list for its KEYWORDS
argument. If you were passing a single string, please update it to a
list with a string instead. Also read the updated doc string of the
'denote' command.
The previous implementation was returning a relative path if the notes'
directory was declared a project, per project.el. The relative path was
not a valid value for our purposes.
Thanks to Jean-Philippe Gagné Guay for the feedback and brainstorming in
issue 42 over at the GitHub mirror:
<https://github.com/protesilaos/denote/pull/42>.
Thanks to Jean-Philippe Gagné Guay for the feedback in issue 41 over at
the GitHub mirror: <https://github.com/protesilaos/denote/issues/41>.
Co-authored-by: Jean-Philippe Gagné Guay <jeanphilippe150@gmail.com>
This is done in order not to break user-level custom code, such as what
we had in the manual:
(defun prot/denote-journal ()
"Create an entry tagged 'journal', while prompting for a title."
(interactive)
(denote
(denote--title-prompt)
"journal"))
Even though 'denote' itself does not require external programs, some
of Emacs' features require external programs. The 'xref' package is
one of those features.
While some of xref's features do not need any external applications,
the function 'xref-matches-in-files' used in 'denote-retrieve--xrefs'
will use 'xref-search-program' and by that also the associative list
'xref-search-program-alist' to find the actual shell command. As
`-in-files` the suffix implies, the shell command needs to understand
multiple file names, which is the reason for 'xargs' in the pipe.
Since there is no Windows native alternative for 'xargs', the user
needs to install one of the many packages like msys64, MinGW, or Git,
that provide the necessary tools within their installation.
Afterwards, the path has to be added to the ~%PATH%~ environment
variable. Note that 'exec-path' is not enough, since the shell proxy
on Windows, 'cmdproxy.exe', does not know about that Lisp-only
variable.
Either setting the PATH variable within Emacs as shown in the
changeset or setting the PATH variable within Windows' settings should
suffice and therefore get rid of this issue.
All file type extensions make for valid Denote-style names. The
'denote--extension-regexp' is only really needed for those files which
we consider "notes" as opposed to, say, an mp3 file.
denote--inferred-keywords now delete duplicates.
Removal of denote--keywords-in-files.
Refactor denote--extract into denote--extract-keywords-from-path.
The user option denote-prompts allows the user to specify the prompts
of the denote command and their order.
Refactor 'denote-type', 'denote-date', and 'denote-subdirectory' to
use the 'denote' command.