Hello,
I have written the following functions, that help me open or link to
journal entries, which follow a specific naming scheme (i.e., the date
spelled out).
(defun as/denote-journal-open ()
(interactive)
(let* ((date (org-read-date))
(time (org-time-string-to-time date))
(title (format-time-string "%A %d %B %Y" time))
(initial (denote-sluggify title))
(target (read-file-name "Select note: " (denote-directory) nil nil initial
(lambda (f)
(or (denote-file-has-identifier-p f)
(file-directory-p f))))))
(if (file-exists-p target)
(find-file target)
(denote title '("journal") 'org nil date))))
(defun as/denote-journal-link ()
(interactive)
(let* ((date (org-read-date))
(time (org-time-string-to-time date))
(title (format-time-string "%A %d %B %Y" time))
(initial (denote-sluggify title))
(target (read-file-name "Select note: " (denote-directory) nil nil initial
(lambda (f)
(or (denote-file-has-identifier-p f)
(file-directory-p f))))))
(if (file-exists-p target)
(denote-link target)
(let (path)
(save-window-excursion
(denote title '("journal") 'org nil date)
(save-buffer)
(setq path (buffer-file-name)))
(denote-link path)))))
The suggestion: these functions could be simplified if
denote-file-prompt took an optional argument that is the initial input
string. Would you accept such a patch?
The question: I need to duplicate the code of denote-open-or-create
(which is simple) and denote-link-or-create (which is more complex).
Could there be a way to reuse these functions?
Thanks,
Alan
> From: alan.schmitt@polytechnique.org> Date: Wed, 5 Oct 2022 15:16:18 +0200>> Hello,
Hello Alan,
> I have written the following functions, that help me open or link to> journal entries, which follow a specific naming scheme (i.e., the date> spelled out).>> [... 32 lines elided]>> The suggestion: these functions could be simplified if> denote-file-prompt took an optional argument that is the initial input> string. Would you accept such a patch?
Yes, that patch makes sense. Thank you! Do you want to prepare it, or
shall I just make the change from here? If you do it, don't worry about
the documentation of it: I will handle it.
> The question: I need to duplicate the code of denote-open-or-create> (which is simple) and denote-link-or-create (which is more complex).> Could there be a way to reuse these functions?
I guess it depends on what this entails. The functions are small, so
you could copy and then modify them if nothing else works. Though I
will likely have a more specific suggestion if you describe what your
intent is with them.
All the best,
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Hello Prot,
On 2022-10-05 17:13, Protesilaos Stavrou <info@protesilaos.com> writes:
>> The suggestion: these functions could be simplified if>> denote-file-prompt took an optional argument that is the initial input>> string. Would you accept such a patch?>> Yes, that patch makes sense. Thank you! Do you want to prepare it, or> shall I just make the change from here? If you do it, don't worry about> the documentation of it: I will handle it.
Since the change is so tiny, I think it’s faster if you directly do it.
>> The question: I need to duplicate the code of denote-open-or-create>> (which is simple) and denote-link-or-create (which is more complex).>> Could there be a way to reuse these functions?>> I guess it depends on what this entails. The functions are small, so> you could copy and then modify them if nothing else works. Though I> will likely have a more specific suggestion if you describe what your> intent is with them.
I was thinking that denote-open-or-create (and link) could take optional
parameters such as title, keywords, and date. If the parameters are not
provided, then the user is prompted for them as usual, otherwise they
are not.
Right now the code of these functions use (call-interactively #'denote),
and I don’t know if it’s possible to pass some arguments to this call…
Best,
Alan
> From: Alan Schmitt <alan.schmitt@polytechnique.org>> Date: Wed, 5 Oct 2022 16:36:53 +0200>> Hello Prot,>> On 2022-10-05 17:13, Protesilaos Stavrou <info@protesilaos.com> writes:>>>> The suggestion: these functions could be simplified if>>> denote-file-prompt took an optional argument that is the initial input>>> string. Would you accept such a patch?>>>> Yes, that patch makes sense. Thank you! Do you want to prepare it, or>> shall I just make the change from here? If you do it, don't worry about>> the documentation of it: I will handle it.>> Since the change is so tiny, I think it’s faster if you directly do it.
Done. Thank you!
commit c6c3fc95c66ba093a266c775f411c0c8615c14c7
Author: Protesilaos Stavrou <info@protesilaos.com>
Date: Wed Oct 5 17:50:52 2022 +0300
Add optional INITIAL-TEXT to denote-file-prompt
Thanks to Alan Schmitt for suggesting the idea:
<https://lists.sr.ht/~protesilaos/denote/%3C87pmf676n1.fsf@m4x.org%3E>.
README.org | 3 ++-
denote.el | 7 ++++---
2 files changed, 6 insertions(+), 4 deletions(-)
>>> The question: I need to duplicate the code of denote-open-or-create>>> (which is simple) and denote-link-or-create (which is more complex).>>> Could there be a way to reuse these functions?>>>> I guess it depends on what this entails. The functions are small, so>> you could copy and then modify them if nothing else works. Though I>> will likely have a more specific suggestion if you describe what your>> intent is with them.>> I was thinking that denote-open-or-create (and link) could take optional> parameters such as title, keywords, and date. If the parameters are not> provided, then the user is prompted for them as usual, otherwise they> are not.>> Right now the code of these functions use (call-interactively #'denote),> and I don’t know if it’s possible to pass some arguments to this call…
Adding those optional arguments will make the interactive spec more
complex, as it will duplicate that of 'denote' with the addition of the
conditionality that checks if TARGET exists before promting for all the
rest.
I am fine with making such a change. perhaps by adding a non-interactive
function that does this job. Though I think it is too early to add it
to denote.el. It feels idiosyncratic because the TARGET argument is
practical when used interactively while all the others are helpful only
when called from Lisp.
Furthermore, when we are calling it from Lisp, we can do more with how
we retrieve the TARGET, to the effect that we may not need to call
'denote' at all.
At any rate, here is the very basic tweak on what we have:
(defun denote-open-or-create-1
(target &optional title keywords file-type subdirectory date template)
"Visit TARGET file in variable `denote-directory'.
If file does not exist, invoke `denote' to create a file.
Optional TITLE, KEYWORDS, FILE-TYPE, SUBDIRECTORY, DATE, and
TEMPLATE are all passed to `denote'. They have the meaning
described in its doc string."
(if (file-exists-p target)
(find-file target)
(denote title keywords file-type subdirectory date template)))
And then it can be used with something like this:
(denote-open-or-create-1
"a non-existent file"
"Some test title"
'("testing" "denote" "keywords")
'org)
[ By "too early" I mean that the initial implementation was done in that
limited way to (i) explore whether the functions are useful and (ii)
provide a convenience sample to show how something like this can be
achieved with minimal code. Hence all the variants we added in the
manual for 'denote-link-or-create' and the 'denote-open-or-create'. ]
--
Protesilaos Stavrou
https://protesilaos.com
Hello Prot,
On 2022-10-05 18:15, Protesilaos Stavrou <info@protesilaos.com> writes:
> Done. Thank you!
This is great. I’ll pull and use it immediately.
>> I was thinking that denote-open-or-create (and link) could take optional>> parameters such as title, keywords, and date. If the parameters are not>> provided, then the user is prompted for them as usual, otherwise they>> are not.>>>> Right now the code of these functions use (call-interactively #'denote),>> and I don’t know if it’s possible to pass some arguments to this call…>> Adding those optional arguments will make the interactive spec more> complex, as it will duplicate that of 'denote' with the addition of the> conditionality that checks if TARGET exists before promting for all the> rest.>> I am fine with making such a change. perhaps by adding a non-interactive> function that does this job. Though I think it is too early to add it> to denote.el. It feels idiosyncratic because the TARGET argument is> practical when used interactively while all the others are helpful only> when called from Lisp.
I understand, and I guess my use case is very specialized. The code I
have is very similar to the one you suggested in the rest of your
message, and it could be mentioned only in the manual.
Thanks again,
Alan