~protesilaos/denote

13 3

New commands to link to existing or new note

Details
Message ID
<87fsgvddny.fsf@protesilaos.com>
DKIM signature
missing
Download raw message
Hello folks,

Just to inform you about two new commands I just published.  The manual
explains the rationale:[1]

    [ The 'denote-link-after-creating' and 'denote-link-or-create' are
      part of version 1.0.0-dev. ]

    In one's note-taking workflow, there may come a point where they are
    expounding on a certain topic but have an idea about another subject
    they would like to link to (see "Linking notes").  The user can
    always rely on the other linking facilities we have covered herein
    to target files that already exist.  Though they may not know
    whether they already have notes covering the subject or whether they
    would need to write new ones.  To this end, Denote provides two
    convenience commands:

    + 'denote-link-after-creating' :: Create new note in the background
      and link to it directly.

      [...]

    + 'denote-link-or-create' :: Use 'denote-link' on 'TARGET' file,
      creating it if necessary.

      [...]

This was originally discussed on the GitHub mirror.[2]

These commands are part of the current development target.  This means
that they (i) are not available in the regular GNU ELPA package just
yet, and (ii) may still be tweaked further.  They will become widely
available when I eventually release version 1.0.0, though this will take
a while longer.

All the best,
Protesilaos (or simply "Prot")

[1] <https://protesilaos.com/emacs/denote#h:9e41e7df-2aac-4835-94c5-659b6111e6de>
[2] <https://github.com/protesilaos/denote/issues/96#issuecomment-1240125724>

-- 
Protesilaos Stavrou
https://protesilaos.com
Marc Fargas <marc@marcfargas.com>
Details
Message ID
<875yhr390k.fsf@marcfargas.com>
In-Reply-To
<87fsgvddny.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hi,

El mar. 13 de sep. 2022,  Protesilaos escribió
>     + 'denote-link-after-creating' :: Create new note in the background
>       and link to it directly.
>       [...]
>
>     + 'denote-link-or-create' :: Use 'denote-link' on 'TARGET' file,
>       creating it if necessary.
>       [...]

Orgmode, on capture and/or refile, creates an Emacs bookmark pointing to
the affected element which makes it very quick to jump there.

Maybe those functions (and others that create notes) could have a similar functionality?

See, on org-capture.el :

- org-capture-bookmark (configuration setting / variable)
- org-capture-store-last-position (function that creates the bookmark)

That probably goes onto "wishlist" / "someday" bucket. Which brings the
question... where should wishlist items be kept? I don't see an Issues /
Tickets option in SourceHut ?

marc
Details
Message ID
<87sfkvk32c.fsf@protesilaos.com>
In-Reply-To
<875yhr390k.fsf@marcfargas.com> (view parent)
DKIM signature
missing
Download raw message
> From: Marc Fargas <marc@marcfargas.com>
> Date: Tue, 13 Sep 2022 11:42:51 +0200
>
> Hi,

Hello Marc,

> El mar. 13 de sep. 2022,  Protesilaos escribió
>>     + 'denote-link-after-creating' :: Create new note in the background
>>       and link to it directly.
>>       [...]
>>
>>     + 'denote-link-or-create' :: Use 'denote-link' on 'TARGET' file,
>>       creating it if necessary.
>>       [...]
>
> Orgmode, on capture and/or refile, creates an Emacs bookmark pointing to
> the affected element which makes it very quick to jump there.
>
> Maybe those functions (and others that create notes) could have a similar functionality?
>
> See, on org-capture.el :
>
> - org-capture-bookmark (configuration setting / variable)
> - org-capture-store-last-position (function that creates the bookmark)

In principle, I am fine with this for all relevant commands.  Though it
would need to not introduce too much complexity to the code base.  It
will also need to work with all supported file types.  Is this possible?
a quick look at org-capture.el tells me that it is not as
straightforward as doing a simple 'bookmark-set'.

In terms of the user-facing aspect, such a feature would be disabled by
default.  It interferes with the user's stored bookmarks even if it is
not especially intrusive.  Receiving explicit consent feels appropriate.

What do you think?

> That probably goes onto "wishlist" / "someday" bucket. Which brings the
> question... where should wishlist items be kept? I don't see an Issues /
> Tickets option in SourceHut ?

Maybe we can add it to the manual?  There is a section with such items,
titled "Things to do":
<https://protesilaos.com/emacs/denote#h:044a6a0f-e382-4013-8279-8bf4e64e73c0>.

All the best,
Protesilaos (or simply "Prot")

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87r10bgz93.fsf@m4x.org>
In-Reply-To
<87fsgvddny.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hello,

On 2022-09-13 08:52, Protesilaos Stavrou <info@protesilaos.com> writes:

>     + 'denote-link-or-create' :: Use 'denote-link' on 'TARGET' file,
>       creating it if necessary.

I find this function most useful in my workflow, but sometimes I need a
little bit more:
- be able to specify a date (typically to create a journal entry)
- open a note instead of linking to it

Here are some tiny proposals for that (with no doc string at the moment)

(defun denote-link-or-create-with-date ()
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-link-or-create)))

(defun denote-open-or-create (target)
  (interactive (list (denote-file-prompt)))
  (if (file-exists-p target)
      (find-file target)
    (call-interactively #'denote)))

(defun denote-open-or-create-with-date ()
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-open-or-create)))

One small question: I see that denote-link-or-create takes some
arguments. Should they be also taken by denote-link-or-create-with-date?

Best,

Alan
Details
Message ID
<87sfkri8lt.fsf@protesilaos.com>
In-Reply-To
<87r10bgz93.fsf@m4x.org> (view parent)
DKIM signature
missing
Download raw message
> From: Alan Schmitt <alan.schmitt@petitepomme.net>
> Date: Fri, 16 Sep 2022 16:39:04 +0200
>
> Hello,

Hello Alan,

> On 2022-09-13 08:52, Protesilaos Stavrou <info@protesilaos.com> writes:
>
>>     + 'denote-link-or-create' :: Use 'denote-link' on 'TARGET' file,
>>       creating it if necessary.
>
> I find this function most useful in my workflow, but sometimes I need a
> little bit more:

A general point here: I think it is useful to maintain a section in the
manual with all sorts of tweaks to existing commands.  Adding everything
directly to denote.el might overload the user with options.

Part of my motivation to have the various commands was to showcase how
to re-use Denote's code to do things a bit differently.  For example,
the doc string of this function and the small code tells us a lot about
this rationale:

    (defun denote-type ()
      "Create note while prompting for a file type.

    This is the equivalent to calling `denote' when `denote-prompts'
    is set to \\='(file-type title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(file-type title keywords)))
        (call-interactively #'denote)))

If we can have such neat ideas in the manual, it will be helpful for
everyone.

> - be able to specify a date (typically to create a journal entry)
> - open a note instead of linking to it
>
> Here are some tiny proposals for that (with no doc string at the moment)
>
> (defun denote-link-or-create-with-date ()
>   (interactive)
>   (let ((denote-prompts '(date title keywords)))
>     (call-interactively #'denote-link-or-create)))
>
> (defun denote-open-or-create (target)
>   (interactive (list (denote-file-prompt)))
>   (if (file-exists-p target)
>       (find-file target)
>     (call-interactively #'denote)))
>
> (defun denote-open-or-create-with-date ()
>   (interactive)
>   (let ((denote-prompts '(date title keywords)))
>     (call-interactively #'denote-open-or-create)))

I like them!  They are consistent with what we have in denote.el and
what I would like to compile as a list of "useful snippets" for the
manual.

Do you want to formally contribute those via a patch or pull request?
Do not worry about adding extra text.  I can handle the documentation.
I am happy to answer any questions you may have.

> One small question: I see that denote-link-or-create takes some
> arguments. Should they be also taken by denote-link-or-create-with-date?

Based on its current definition, the answer is negative.  All it does is
call denote-link-or-create interactively, so it is not passing those
arguments to the function.  If you want to do that, then you will have
to accept the same arguments but then call the function directly instead
of using 'call-interactively'.  I don't think you need to do that
though.

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87a66xgiom.fsf@m4x.org>
In-Reply-To
<87sfkri8lt.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hello Prot,

On 2022-09-16 19:31, Protesilaos Stavrou <info@protesilaos.com> writes:

> Do you want to formally contribute those via a patch or pull request?
> Do not worry about adding extra text.  I can handle the documentation.
> I am happy to answer any questions you may have.

Here is a patch I created with magit. I hope it’s correctly formatted
(otherwise I can change it).
Details
Message ID
<87o7vcyiqv.fsf@protesilaos.com>
In-Reply-To
<87a66xgiom.fsf@m4x.org> (view parent)
DKIM signature
missing
Download raw message
> From: Alan Schmitt <alan.schmitt@petitepomme.net>
> Date: Sun, 18 Sep 2022 11:01:29 +0200
>
> Hello Prot,

Hello Alan,

> On 2022-09-16 19:31, Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> Do you want to formally contribute those via a patch or pull request?
>> Do not worry about adding extra text.  I can handle the documentation.
>> I am happy to answer any questions you may have.
>
> Here is a patch I created with magit. I hope it’s correctly formatted
> (otherwise I can change it).

It is good.  Thank you!

>From 16e98b1c2d6f2e49f93084438a9c746c270b4b05 Mon Sep 17 00:00:00 2001
> From: Alan Schmitt <alan.schmitt@polytechnique.org>
> Date: Sun, 18 Sep 2022 10:53:04 +0200
> Subject: [PATCH] New utility functions
>
> - `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

> [... 31 lines elided]

I will install your patch, which applies to denote.el.  Though I think
we need to discuss the "-with-date" variants.  Should we keep those in
denote.el or move them to the manual?

If we keep them in denote.el, then we need to complement them with
commands that do '-with-type', '-with-subdirectory', and
'-with-template'.  That way we have symmetry with the other convenience
commands.

The alternative of moving them to the manual offers a MINOR advantage of
not expanding the denote.el code.  Though I don't worry about it for
those commands: they are tiny.

Any thoughts?

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87illkyhhz.fsf@protesilaos.com>
In-Reply-To
<87o7vcyiqv.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Sun, 18 Sep 2022 15:22:48 +0300
>
>> From: Alan Schmitt <alan.schmitt@petitepomme.net>
>> Date: Sun, 18 Sep 2022 11:01:29 +0200

> [... 16 lines elided]

>>From 16e98b1c2d6f2e49f93084438a9c746c270b4b05 Mon Sep 17 00:00:00 2001
>> From: Alan Schmitt <alan.schmitt@polytechnique.org>
>> Date: Sun, 18 Sep 2022 10:53:04 +0200
>> Subject: [PATCH] New utility functions
>>
>> - `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
>
>> [... 31 lines elided]
>
> I will install your patch, which applies to denote.el.  Though I think
> we need to discuss the "-with-date" variants.  Should we keep those in
> denote.el or move them to the manual?
>
> If we keep them in denote.el, then we need to complement them with
> commands that do '-with-type', '-with-subdirectory', and
> '-with-template'.  That way we have symmetry with the other convenience
> commands.
>
> The alternative of moving them to the manual offers a MINOR advantage of
> not expanding the denote.el code.  Though I don't worry about it for
> those commands: they are tiny.
>
> Any thoughts?

Please ignore what I wrote here.  I did include everything in denote.el,
as it is easier for users.  Though documenting other such variants
should be the way to go, just to keep things maintainable.

This is the code we have now based on the changes I made:

    ;;;###autoload
    (defun denote-link-or-create-with-date ()
      "Invoke `denote-link-or-create' but also prompt for date.

    The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
    that plus the time: 2022-06-16 14:30.  When the user option
    `denote-date-prompt-use-org-read-date' is non-nil, the date
    prompt uses the more powerful Org+calendar system.

    This is the equivalent to calling `denote-link-or-create' when
    `denote-prompts' is set to \\='(date title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(date title keywords)))
        (call-interactively #'denote-link-or-create)))

    ;;;###autoload
    (defun denote-link-or-create-with-type ()
      "Invoke `denote-link-or-create' but also prompt for file type.
    This is the equivalent to calling `denote-link-or-create' when
    `denote-prompts' is set to \\='(type title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(type title keywords)))
        (call-interactively #'denote-link-or-create)))

    ;;;###autoload
    (defun denote-link-or-create-with-subdirectory ()
      "Invoke `denote-link-or-create' but also prompt for subdirectory.
    This is the equivalent to calling `denote-link-or-create' when
    `denote-prompts' is set to \\='(subdirectory title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(subdirectory title keywords)))
        (call-interactively #'denote-link-or-create)))

    ;;;###autoload
    (defun denote-link-or-create-with-template ()
      "Invoke `denote-link-or-create' but also prompt for template.
    This is the equivalent to calling `denote-link-or-create' when
    `denote-prompts' is set to \\='(template title keywords).

    For templates, refer to `denote-templates'."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(template title keywords)))
        (call-interactively #'denote-link-or-create)))

    ;;;###autoload
    (defun denote-open-or-create (target)
      "Visit file in variable `denote-directory'.
    If file does not exist, invoke `denote' to create a file."
      (interactive (list (denote-file-prompt)))
      (if (file-exists-p target)
          (find-file target)
        (call-interactively #'denote)))

    ;;;###autoload
    (defun denote-open-or-create-with-date ()
      "Invoke `denote-link-or-create' but also prompt for date.

    The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
    that plus the time: 2022-06-16 14:30.  When the user option
    `denote-date-prompt-use-org-read-date' is non-nil, the date
    prompt uses the more powerful Org+calendar system.

    This is the equivalent to calling `denote-link-or-create' when
    `denote-prompts' is set to \\='(date title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(date title keywords)))
        (call-interactively #'denote-open-or-create)))

    ;;;###autoload
    (defun denote-open-or-create-with-type ()
      "Invoke `denote-open-or-create' but also prompt for file type.
    This is the equivalent to calling `denote-open-or-create' when
    `denote-prompts' is set to \\='(type title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(type title keywords)))
        (call-interactively #'denote-open-or-create)))

    ;;;###autoload
    (defun denote-open-or-create-with-subdirectory ()
      "Invoke `denote-open-or-create' but also prompt for subdirectory.
    This is the equivalent to calling `denote-open-or-create' when
    `denote-prompts' is set to \\='(subdirectory title keywords)."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(subdirectory title keywords)))
        (call-interactively #'denote-open-or-create)))

    ;;;###autoload
    (defun denote-open-or-create-with-template ()
      "Invoke `denote-open-or-create' but also prompt for template.
    This is the equivalent to calling `denote-open-or-create' when
    `denote-prompts' is set to \\='(template title keywords).

    For templates, refer to `denote-templates'."
      (declare (interactive-only t))
      (interactive)
      (let ((denote-prompts '(template title keywords)))
        (call-interactively #'denote-open-or-create)))

I will also document them in the manual.  Though this will be done a bit
later in the day.

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<874jx4h9cl.fsf@m4x.org>
In-Reply-To
<87illkyhhz.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hello Prot,

On 2022-09-18 15:49, Protesilaos Stavrou <info@protesilaos.com> writes:

> Please ignore what I wrote here.  I did include everything in denote.el,
> as it is easier for users.  Though documenting other such variants
> should be the way to go, just to keep things maintainable.
>
> This is the code we have now based on the changes I made:

This looks great, but I’m thinking about opening a big can of worms…

I only use date variants (flat hierarchy of org files, and no
templates). But what if one uses all four options (date, type,
subdirectory, template)? Should we have 16 versions of each interactive
function?

The only alternative I can think of is to prompt the user in a smart way
for everything:
- for the date, the default choice is the current date
- for the type, the default choice is the current type
- for subdirectory and templates, only prompt if they exist

Such a variant could be a `denote-...-full' version.

To sum up, the alternatives I can think of for n options are:
- denote + denote-full: 2 commands
- denote + denote-1option + denote-full: n+2 commands
- all options: 2^n commands

I think the second one might be a good compromise, as one may not often
need more than one extra prompt. But then one still need to code the
"full" version of most commands (the tricky bit being the default for
the template and subdirectory options). I unfortunately have several
students defending their PhDs in the coming weeks, but if you think this
is of interest, I can give it a try. Please let me know what you think.

Best,

Alan
Details
Message ID
<87leqg4ldf.fsf@protesilaos.com>
In-Reply-To
<874jx4h9cl.fsf@m4x.org> (view parent)
DKIM signature
missing
Download raw message
> From: Alan Schmitt <alan.schmitt@petitepomme.net>
> Date: Sun, 18 Sep 2022 19:37:46 +0200
>
> Hello Prot,

Hello Alan,

> On 2022-09-18 15:49, Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> Please ignore what I wrote here.  I did include everything in denote.el,
>> as it is easier for users.  Though documenting other such variants
>> should be the way to go, just to keep things maintainable.
>>
>> This is the code we have now based on the changes I made:
>
> This looks great, but I’m thinking about opening a big can of worms…

No worries.  We are still in development.  It is easy to implement a
change and discuss it than to do the discussion without any code in
hand.

> I only use date variants (flat hierarchy of org files, and no
> templates). But what if one uses all four options (date, type,
> subdirectory, template)? Should we have 16 versions of each interactive
> function?

No, we shouldn't have all variants for all commands.  That will just
make things harder on the maintenance front.  When something is in
denote.el, it needs to be documented clearly, tested each time, and so
on.

> The only alternative I can think of is to prompt the user in a smart way
> for everything:
> - for the date, the default choice is the current date
> - for the type, the default choice is the current type
> - for subdirectory and templates, only prompt if they exist
>
> Such a variant could be a `denote-...-full' version.

We already sort of have a "denote full", which is the 'denote' command
when it is called from Lisp with all the arguments it accepts OR when
the 'denote-prompts' is set accordingly to include all the prompts (as
explained by its doc string).

Perhaps what you mean here is a "meta prompt" that asks which prompts to
use and then call them sequentially?  If so, we can try to prototype it
and see what we think about it.

> To sum up, the alternatives I can think of for n options are:
> - denote + denote-full: 2 commands
> - denote + denote-1option + denote-full: n+2 commands
> - all options: 2^n commands
>
> I think the second one might be a good compromise, as one may not often
> need more than one extra prompt. But then one still need to code the
> "full" version of most commands (the tricky bit being the default for
> the template and subdirectory options). I unfortunately have several
> students defending their PhDs in the coming weeks, but if you think this
> is of interest, I can give it a try. Please let me know what you think.

I am happy if you give it a try.  Though note that you will need to do
the copyright assignment process, as your last contribution was on the
limit of what is allowed without such an assignment.  In the manual,
there is a form you can use, which mentions the email you need to send
it to (you do not have to send any private information to me, just to
the Free Software Foundation):
<https://protesilaos.com/emacs/denote#h:1ebe4865-c001-4747-a6f2-0fe45aad71cd>.

That granted, there is no need to go out of your way for this.  I assume
you have a lot of work with those students, so adding an extra burden
isn't ideal.  Furthermore, we do not have deadlines here.  Even after
version 1.0.0 is released, we will still be around for 1.1.0, and so on.

My suggestion for the next immediate step is to focus on the topic of
whether we move some code to the manual.  My idea is to (i) keep
'denote-open-or-create' and 'denote-link-or-create' in denote.el, (ii)
move all their derivative commands to the manual where I will create a
dedicated section and explain everything in detail.

Then, when we have a more elegant solution and/or time, we review what
we have and act accordingly.  No stress.

What do you think?

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87illk4k3h.fsf@protesilaos.com>
In-Reply-To
<87leqg4ldf.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Patch: +144 -96
> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Sun, 18 Sep 2022 20:56:28 +0300

> [... 74 lines elided]

> My suggestion for the next immediate step is to focus on the topic of
> whether we move some code to the manual.  My idea is to (i) keep
> 'denote-open-or-create' and 'denote-link-or-create' in denote.el, (ii)
> move all their derivative commands to the manual where I will create a
> dedicated section and explain everything in detail.

> [... 8 lines elided]

Just to be concrete with what I meant in my previous message, I propose
this change (subject to minor tweaks in the manual's wording):


 README.org | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 denote.el  |  96 -----------------------------------------
 2 files changed, 144 insertions(+), 96 deletions(-)

diff --git a/README.org b/README.org
index 6bdb306..7f33bd1 100644
--- a/README.org
+++ b/README.org
@@ -1861,6 +1861,150 @@ ** Treat your notes as a project
package will get the job done (VC can work with other backends besides
Git).

** Variants of ~denote-open-or-create~
:PROPERTIES:
:CUSTOM_ID: h:ad91ca39-cf10-4e16-b224-fdf78f093883
:END:

#+findex: denote-open-or-create
The command ~denote-open-or-create~ prompts to visit a file in the
~denote-directory~.  If the user input does not have any matches,
~denote-open-or-create~ will call the ~denote~ command interactively.
It will then use whatever prompts ~denote~ normally has, per the user
option ~denote-prompts~ ([[#h:6a92a8b5-d766-42cc-8e5b-8dc255466a23][Standard note creation]]).

To speed up the process or to maintain variants that suit one's
workflow, we provide these ready-to-use commands that one can add to
their Emacs init file.  They can be assigned to key bindings or be used
via =M-x= after they have been evaluated.

#+begin_src emacs-lisp
;;;###autoload
(defun denote-open-or-create-with-date ()
  "Invoke `denote-open-or-create' but also prompt for date.

The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
that plus the time: 2022-06-16 14:30.  When the user option
`denote-date-prompt-use-org-read-date' is non-nil, the date
prompt uses the more powerful Org+calendar system.

This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(date title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-type ()
  "Invoke `denote-open-or-create' but also prompt for file type.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(type title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(type title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-subdirectory ()
  "Invoke `denote-open-or-create' but also prompt for subdirectory.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(subdirectory title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(subdirectory title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-template ()
  "Invoke `denote-open-or-create' but also prompt for template.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(template title keywords).

For templates, refer to `denote-templates'."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(template title keywords)))
    (call-interactively #'denote-open-or-create)))
#+end_src

** Variants of ~denote-link-or-create~
:PROPERTIES:
:CUSTOM_ID: h:b6056e6b-93df-4e6b-a778-eebd105bac46
:END:

#+findex: denote-link-or-create
The command ~denote-link-or-create~ uses ~denote-link~ on a =TARGET=
file, creating it if necessary.  The =TARGET= matches the user input at
a minibuffer prompt: it is a file in the ~denote-directory~.

#+findex: denote-link-after-creating
If =TARGET= file does not exist, The ~denote-link-or-create~ calls
~denote-link-after-creating~ which runs the standard ~denote~ command
interactively to create the file ([[#h:6a92a8b5-d766-42cc-8e5b-8dc255466a23][Standard note creation]]).  The
established link will then be targeting that new file.

When called with an optional prefix argument (=C-u= by default)
~denote-link-or-create~ creates a link that consists of just the
identifier.  Else it tries to also include the file's title.  This has
the same meaning as in ~denote-link~ ([[#h:fc913d54-26c8-4c41-be86-999839e8ad31][Linking notes]]).

To speed up the process or to maintain variants that suit one's
workflow, we provide these ready-to-use commands that one can add to
their Emacs init file.  They can be assigned to key bindings or be used
via =M-x= after they have been evaluated.

#+begin_src emacs-lisp

;;;###autoload
(defun denote-link-or-create-with-date ()
  "Invoke `denote-link-or-create' but also prompt for date.

The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
that plus the time: 2022-06-16 14:30.  When the user option
`denote-date-prompt-use-org-read-date' is non-nil, the date
prompt uses the more powerful Org+calendar system.

This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(date title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-type ()
  "Invoke `denote-link-or-create' but also prompt for file type.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(type title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(type title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-subdirectory ()
  "Invoke `denote-link-or-create' but also prompt for subdirectory.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(subdirectory title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(subdirectory title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-template ()
  "Invoke `denote-link-or-create' but also prompt for template.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(template title keywords).

For templates, refer to `denote-templates'."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(template title keywords)))
    (call-interactively #'denote-link-or-create)))
#+end_src

* Installation
:PROPERTIES:
:CUSTOM_ID: h:f3bdac2c-4704-4a51-948c-a789a2589790
diff --git a/denote.el b/denote.el
index 0ef50a2..485a8a5 100644
--- a/denote.el
+++ b/denote.el
@@ -1495,54 +1495,6 @@ (defun denote-open-or-create (target)
      (find-file target)
    (call-interactively #'denote)))

;;;###autoload
(defun denote-open-or-create-with-date ()
  "Invoke `denote-open-or-create' but also prompt for date.

The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
that plus the time: 2022-06-16 14:30.  When the user option
`denote-date-prompt-use-org-read-date' is non-nil, the date
prompt uses the more powerful Org+calendar system.

This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(date title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-type ()
  "Invoke `denote-open-or-create' but also prompt for file type.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(type title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(type title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-subdirectory ()
  "Invoke `denote-open-or-create' but also prompt for subdirectory.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(subdirectory title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(subdirectory title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;###autoload
(defun denote-open-or-create-with-template ()
  "Invoke `denote-open-or-create' but also prompt for template.
This is the equivalent to calling `denote-open-or-create' when
`denote-prompts' is set to \\='(template title keywords).

For templates, refer to `denote-templates'."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(template title keywords)))
    (call-interactively #'denote-open-or-create)))

;;;; Note modification

;;;;; Common helpers for note modifications
@@ -2332,54 +2284,6 @@ (defun denote-link-or-create (target &optional id-only)

(defalias 'denote-link-to-existing-or-new-note (symbol-function 'denote-link-or-create))

;;;###autoload
(defun denote-link-or-create-with-date ()
  "Invoke `denote-link-or-create' but also prompt for date.

The date can be in YEAR-MONTH-DAY notation like 2022-06-30 or
that plus the time: 2022-06-16 14:30.  When the user option
`denote-date-prompt-use-org-read-date' is non-nil, the date
prompt uses the more powerful Org+calendar system.

This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(date title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(date title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-type ()
  "Invoke `denote-link-or-create' but also prompt for file type.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(type title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(type title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-subdirectory ()
  "Invoke `denote-link-or-create' but also prompt for subdirectory.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(subdirectory title keywords)."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(subdirectory title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;###autoload
(defun denote-link-or-create-with-template ()
  "Invoke `denote-link-or-create' but also prompt for template.
This is the equivalent to calling `denote-link-or-create' when
`denote-prompts' is set to \\='(template title keywords).

For templates, refer to `denote-templates'."
  (declare (interactive-only t))
  (interactive)
  (let ((denote-prompts '(template title keywords)))
    (call-interactively #'denote-link-or-create)))

;;;;; Link buttons

;; Evaluate: (info "(elisp) Button Properties")


-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87pmfrg8xv.fsf@m4x.org>
In-Reply-To
<87leqg4ldf.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hello Prot,

On 2022-09-18 20:56, Protesilaos Stavrou <info@protesilaos.com> writes:

> We already sort of have a "denote full", which is the 'denote' command
> when it is called from Lisp with all the arguments it accepts OR when
> the 'denote-prompts' is set accordingly to include all the prompts (as
> explained by its doc string).

What I meant was that it is not currently accessible interactively. I’m
thinking of a user who is happy with the default, and then they need
(for instance) to create a markdown note at a different date. They have
to write some code to be able to do it interactively. If there was a
"denote full" interactive command, they could just call it then (and
they might discover other options they were not aware of).

> I am happy if you give it a try.  Though note that you will need to do
> the copyright assignment process, as your last contribution was on the
> limit of what is allowed without such an assignment.  In the manual,
> there is a form you can use, which mentions the email you need to send
> it to (you do not have to send any private information to me, just to
> the Free Software Foundation):
> <https://protesilaos.com/emacs/denote#h:1ebe4865-c001-4747-a6f2-0fe45aad71cd>.

I did that a long time ago, but maybe I need to extend it to all of
emacs. Here is what I sent:

> [What is the name of the program or package you're contributing to?]
>   Org-mode, which is part of Emacs

Should I send it again for GNU Emacs?

> My suggestion for the next immediate step is to focus on the topic of
> whether we move some code to the manual.  My idea is to (i) keep
> 'denote-open-or-create' and 'denote-link-or-create' in denote.el, (ii)
> move all their derivative commands to the manual where I will create a
> dedicated section and explain everything in detail.

I’ve read your other message, and I honestly have no strong preference
(sorry, not helping much here…) If we assume users will read the manual
and will adapt their configuration accordingly, I’m perfectly fine with
having these customized functions in the manual only.

Best,

Alan
Details
Message ID
<87mtavsu4d.fsf@protesilaos.com>
In-Reply-To
<87pmfrg8xv.fsf@m4x.org> (view parent)
DKIM signature
missing
Download raw message
> From: Alan Schmitt <alan.schmitt@petitepomme.net>
> Date: Mon, 19 Sep 2022 08:44:12 +0200
>
> Hello Prot,

Hello Alan,

> On 2022-09-18 20:56, Protesilaos Stavrou <info@protesilaos.com> writes:
>
>> We already sort of have a "denote full", which is the 'denote' command
>> when it is called from Lisp with all the arguments it accepts OR when
>> the 'denote-prompts' is set accordingly to include all the prompts (as
>> explained by its doc string).
>
> What I meant was that it is not currently accessible interactively. I’m
> thinking of a user who is happy with the default, and then they need
> (for instance) to create a markdown note at a different date. They have
> to write some code to be able to do it interactively. If there was a
> "denote full" interactive command, they could just call it then (and
> they might discover other options they were not aware of).

I understood though I was just pointing out what is currently available.
I think a "denote full" command will be useful.  It will prompt for
something like this:

    Which prompts to use?

    1. title+keywords (default)
    2. date+title+keywords
    3. file-type+title+keywords
    4. subdirectory+title+keywords
    5. template+title+keywords

    [... more permutations ...]

    [ Alternatively, it could be a 'completing-read-multiple' prompt,
      just as we already have for the keywords' prompt. ]

The command will then use whatever the user chooses.  This is just an
idea though.  I have not tested.  Maybe all those prompts will be
unwieldy in practice?

>> I am happy if you give it a try.  Though note that you will need to do
>> the copyright assignment process, as your last contribution was on the
>> limit of what is allowed without such an assignment.  In the manual,
>> there is a form you can use, which mentions the email you need to send
>> it to (you do not have to send any private information to me, just to
>> the Free Software Foundation):
>> <https://protesilaos.com/emacs/denote#h:1ebe4865-c001-4747-a6f2-0fe45aad71cd>.
>
> I did that a long time ago, but maybe I need to extend it to all of
> emacs. Here is what I sent:
>
>> [What is the name of the program or package you're contributing to?]
>>   Org-mode, which is part of Emacs
>
> Should I send it again for GNU Emacs?

No, you are good.  Org and Emacs are the same in this regard.

>> My suggestion for the next immediate step is to focus on the topic of
>> whether we move some code to the manual.  My idea is to (i) keep
>> 'denote-open-or-create' and 'denote-link-or-create' in denote.el, (ii)
>> move all their derivative commands to the manual where I will create a
>> dedicated section and explain everything in detail.
>
> I’ve read your other message, and I honestly have no strong preference
> (sorry, not helping much here…) If we assume users will read the manual
> and will adapt their configuration accordingly, I’m perfectly fine with
> having these customized functions in the manual only.

Okay.  I moved them to the manual, per my other email.  I have the
impression that users do read it: the number one feedback I get is that
the manual is helpful.

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com
Details
Message ID
<87h713g40s.fsf@m4x.org>
In-Reply-To
<87mtavsu4d.fsf@protesilaos.com> (view parent)
DKIM signature
missing
Download raw message
Hello again,

On 2022-09-19 10:25, Protesilaos Stavrou <info@protesilaos.com> writes:

>> What I meant was that it is not currently accessible interactively. I’m
>> thinking of a user who is happy with the default, and then they need
>> (for instance) to create a markdown note at a different date. They have
>> to write some code to be able to do it interactively. If there was a
>> "denote full" interactive command, they could just call it then (and
>> they might discover other options they were not aware of).
>
> I understood though I was just pointing out what is currently available.
> I think a "denote full" command will be useful.  It will prompt for
> something like this:
>
>     Which prompts to use?
>
>     1. title+keywords (default)
>     2. date+title+keywords
>     3. file-type+title+keywords
>     4. subdirectory+title+keywords
>     5. template+title+keywords
>
>     [... more permutations ...]
>
>     [ Alternatively, it could be a 'completing-read-multiple' prompt,
>       just as we already have for the keywords' prompt. ]
>
> The command will then use whatever the user chooses.  This is just an
> idea though.  I have not tested.  Maybe all those prompts will be
> unwieldy in practice?

I’m afraid so. I just tried the following:

(defun denote-full ()
  (interactive)
  (let ((denote-prompts
         (append '(date title keywords file-type subdirectory)
                 (when denote-templates '(template)))))
    (call-interactively #'denote)))

and I actually find it very satisfactory:
- the date defaults to the current date if it does not need to be
  changed
- the default file type and subdirectory are the ones I use, so I only
  hit "enter" (for subdirectories one could be smart and check if there
  are any before asking)
- I have no template so I’m not asked for them

I think doing it this way would be faster than first prompting for which
prompts to use.

>> Should I send it again for GNU Emacs?
>
> No, you are good.  Org and Emacs are the same in this regard.

Great, thanks.

>> I’ve read your other message, and I honestly have no strong preference
>> (sorry, not helping much here…) If we assume users will read the manual
>> and will adapt their configuration accordingly, I’m perfectly fine with
>> having these customized functions in the manual only.
>
> Okay.  I moved them to the manual, per my other email.  I have the
> impression that users do read it: the number one feedback I get is that
> the manual is helpful.

Perfect.

Best,

Alan
Reply to thread Export thread (mbox)