Hello, and congrats on 0.1.0!
I often find myself hung up on choosing keyword(s) for new notes. I don't always feel I need them. I'm also not convinced of their value (to me) in file names. I know that the file naming in Denote has been thoughtfully considered, but I'd like to suggest making keywords optional when creating new files/notes.
The simplest thing might be to adjust denote--format-file so that the "__" string is not added if no keyword is entered. Currently I end up with a filename like 20220627T060114--my-new-note__.org. Ideally it would be 20220627T060114--my-new-note.org
A fancier solution might be a user option to ignore keywords. In this case I would not even be prompted for a keyword when creating new notes.
I understand this may go against the grain of Denote, but I thought I'd ask anyway.
Thank you.
--
Jack Baty
https://baty.net
> From: Jack Baty <jack@baty.net>> Date: Mon, 27 Jun 2022 06:11:20 -0400>> Hello, and congrats on 0.1.0!
Hi Jack and thank you!
> [... 15 lines elided]>> I understand this may go against the grain of Denote, but I thought> I'd ask anyway.
In terms of design, I think a user option as you mentioned would work
better: it states a clear preference.
Changing the 'denote--format-file' is easy and should yield the file
name you expect. A quick test:
(defun denote--format-file (path id keywords slug extension)
"Testing."
(let* ((kws (if denote-infer-keywords
(denote--keywords-combine keywords)
keywords))
(k (if (string= kws "") kws (concat "__" kws)))
(ext (or extension (denote--file-extension))))
(format "%s%s--%s%s%s" path id slug k ext)))
;; Tests
(denote--format-file
(file-name-as-directory (denote-directory))
(format-time-string denote--id-format)
(denote--sluggify-keywords "")
(denote--sluggify "This is a test with no keyword")
(denote--file-extension))
(denote--format-file
(file-name-as-directory (denote-directory))
(format-time-string denote--id-format)
(denote--sluggify-keywords "one")
(denote--sluggify "This is a test with one keyword")
(denote--file-extension))
(denote--format-file
(file-name-as-directory (denote-directory))
(format-time-string denote--id-format)
(denote--sluggify-keywords '("one" "two"))
(denote--sluggify "This is a test with two keywords")
(denote--file-extension))
The real problem is how many things we need to consider to make this
change work properly. What comes to mind:
+ All variables that hold the front matter formats.
+ Any regexp that targets the file name, such as 'denote-dired-mode'.
+ The rename operation and the post-rename replacement of front matter.
We would need to consider all of those. Maybe there are more.
In principle, I am not against this idea but would need to experiment
with it to have a better sense of its costs and/or potential downsides.
What do you think?
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Jack Baty <jack@baty.net>>> Date: Mon, 27 Jun 2022 06:11:20 -0400>>>> In terms of design, I think a user option as you mentioned would work> better: it states a clear preference.> The real problem is how many things we need to consider to make this> change work properly. What comes to mind:>> + All variables that hold the front matter formats.> + Any regexp that targets the file name, such as ’denote-dired-mode’.> + The rename operation and the post-rename replacement of front matter.>> We would need to consider all of those. Maybe there are more.>> In principle, I am not against this idea but would need to experiment> with it to have a better sense of its costs and/or potential downsides.>> What do you think?
Yes, the original filename creation seemed like it would be straightforward enough. But you’re right, there’s a lot to consider around front matter management and renaming. In my case, I often add tags to the front matter after the fact. I don’t need a connection between filename and front matter keywords. I would be fine with seeing #+filetags: with no value in new notes. But, I wouldn’t want mine erased/modified if I were to rename the file later. So yeah, it’s tricky.
This could very well be something of little interest to many, and perhaps not worth the trouble or risks of implementation. I’m happy to tweak my local copy as needed for now. Your examples seem like a nice start. :)
Thanks for talking this through.
Jack
> From: Jack Baty <jack@baty.net>> Date: Mon, 27 Jun 2022 10:58:20 -0400>>> In terms of design, I think a user option as you mentioned would work>> better: it states a clear preference.>> The real problem is how many things we need to consider to make this>> change work properly. What comes to mind:>>>> + All variables that hold the front matter formats.>> + Any regexp that targets the file name, such as ’denote-dired-mode’.>> + The rename operation and the post-rename replacement of front matter.>>>> We would need to consider all of those. Maybe there are more.>>>> In principle, I am not against this idea but would need to experiment>> with it to have a better sense of its costs and/or potential downsides.>>>> What do you think?>> Yes, the original filename creation seemed like it would be> straightforward enough. But you’re right, there’s a lot to consider> around front matter management and renaming.> [... 6 lines elided]> This could very well be something of little interest to many, and> perhaps not worth the trouble or risks of implementation. I’m happy to> tweak my local copy as needed for now. Your examples seem like a nice> start. :)
Hello again, Jack!
Just to note that I have not forgotten about your request here. Also to
inform you that another user has suggested a change on the GitHub mirror
that will make a "no keywords" workflow possible:
<https://github.com/protesilaos/denote/pull/33>.
The code is not final, though the idea is there. We shall explore our
options and proceed accordingly.
All the best,
Protesilaos (or simply "Prot")
--
Protesilaos Stavrou
https://protesilaos.com
Protesilaos Stavrou <info@protesilaos.com> writes:
>> From: Jack Baty <jack@baty.net>>> Date: Mon, 27 Jun 2022 10:58:20 -0400>>>>> In terms of design, I think a user option as you mentioned >>> would work>>> better: it states a clear preference.>>> The real problem is how many things we need to consider to >>> make this>>> change work properly. What comes to mind:>>>>>> + All variables that hold the front matter formats.>>> + Any regexp that targets the file name, such as >>> ’denote-dired-mode’.>>> + The rename operation and the post-rename replacement of >>> front matter.>>>>>> We would need to consider all of those. Maybe there are more.>>>>> [snip]>>>> Yes, the original filename creation seemed like it would be>> straightforward enough. But you’re right, there’s a lot to >> consider>> around front matter management and renaming.>>> [... 6 lines elided]>>> This could very well be something of little interest to many, >> and>> perhaps not worth the trouble or risks of implementation. I’m >> happy to>> tweak my local copy as needed for now. Your examples seem like >> a nice>> start. :)>> Hello again, Jack!>> Just to note that I have not forgotten about your request here. > Also to> inform you that another user has suggested a change on the > GitHub mirror> that will make a "no keywords" workflow possible:> <https://github.com/protesilaos/denote/pull/33>.>> The code is not final, though the idea is there. We shall > explore our> options and proceed accordingly.>> All the best,> Protesilaos (or simply "Prot")
Very nice, thank you! I hadn't seen the Github thread so thank you
for following up.
Jack
Hello again, Jack!
Just to offer a status update on this. Earlier today I merged a branch
which adds support for numerous permutations of file names. This is the
product of a joint effort with Jean-Philippe Gagné Guay.
The idea is that what we count as a "note" can now be like this:
- ID.EXT
- ID--TITLE.EXT
- ID--TITLE__KEYWORDS.EXT
- ID__KEYWORDS.EXT
[ These fields are explained in the manual's section about the
file-naming scheme. ]
We still do not provide any user-facing tools to write notes using those
variations, but we are getting closer to that goal.
More to follow in the coming days.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
> On Jul 9, 2022, at 12:44 PM, Protesilaos Stavrou <info@protesilaos.com> wrote:> > Hello again, Jack!> > Just to offer a status update on this. Earlier today I merged a branch> which adds support for numerous permutations of file names. This is the> product of a joint effort with Jean-Philippe Gagné Guay.> > The idea is that what we count as a "note" can now be like this:> > - ID.EXT> - ID--TITLE.EXT> - ID--TITLE__KEYWORDS.EXT> - ID__KEYWORDS.EXT> > [ These fields are explained in the manual's section about the> file-naming scheme. ]> > We still do not provide any user-facing tools to write notes using those> variations, but we are getting closer to that goal.> > More to follow in the coming days.
This is very exciting, thank you for the update! I've been splitting my notes between
Denote and Org-roam (which I've used for quite some time now) and Denote is
quickly becoming a favored, lighter-weight alternative. It fits my brain better :).
Jack