> `denote-menu' is an extension to the elpa package `denote' and provides
> an interface for viewing your denote files that goes beyond using the
> standard `dired' emacs command to view your `denote-directory'.

Sounds very nice, but I wonder if it wouldn't be nicer to integrate it
directly into the `denote` package so users don't need to install this
additional package.


        Stefan

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Sounds very nice, but I wonder if it wouldn't be nicer to integrate it
> directly into the `denote` package so users don't need to install this
> additional package.

That was my initial thought, but I think that the purpose of the denote
package is for note creation. How a user chooses to view their notes is
up to them. I think including this in denote would (implicitly) impose a
viewing method and so that's why I've decided to make denote-menu a
standalone package.

I'd be interested to hear what Prot (denote's maintainer) thinks about
its inclusion...

Hello Mohamed, Stefan,

> From: Mohamed Suliman <sulimanm@tcd.ie>
> Date: Fri, 27 Jan 2023 13:29:18 +0000
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Sounds very nice, but I wonder if it wouldn't be nicer to integrate it
>> directly into the `denote` package so users don't need to install this
>> additional package.
>
> That was my initial thought, but I think that the purpose of the denote
> package is for note creation. How a user chooses to view their notes is
> up to them. I think including this in denote would (implicitly) impose a
> viewing method and so that's why I've decided to make denote-menu a
> standalone package.
>
> I'd be interested to hear what Prot (denote's maintainer) thinks about
> its inclusion...

I think keeping the two separate is easier for maintenance.  Otherwise
there will be too much for me to take care of.

In theory, we can have an indeterminate number of Denote extensions:
some small, some large.  How useful those are depends on the user's
preferences and requirements.  Setting a precedent where we keep those
decoupled from the "core" will help us avoid uncertainty.

That granted, I am happy to discuss all extension-related issues in the
Denote mailing list.  This includes development topics, announcements of
new versions, general questions...

All the best,
Prot

-- 
Protesilaos Stavrou
https://protesilaos.com

Protesilaos Stavrou <info@protesilaos.com> writes:

> I think keeping the two separate is easier for maintenance.  Otherwise
> there will be too much for me to take care of.
>
> In theory, we can have an indeterminate number of Denote extensions:
> some small, some large.  How useful those are depends on the user's
> preferences and requirements.  Setting a precedent where we keep those
> decoupled from the "core" will help us avoid uncertainty.

I agree. Any updates regarding the inclusion of denote-menu into elpa?

Kind regards

--
Mohamed

>> I think keeping the two separate is easier for maintenance.  Otherwise
>> there will be too much for me to take care of.

The main benefit is for the end-users (and often for the longer-term maintenance).

>> In theory, we can have an indeterminate number of Denote extensions:
>> some small, some large.  How useful those are depends on the user's
>> preferences and requirements.  Setting a precedent where we keep those
>> decoupled from the "core" will help us avoid uncertainty.
>
> I agree. Any updates regarding the inclusion of denote-menu into elpa?

Sorry, I'm more reactive than proactive these days.
I just added it to elpa.git, it should appear in GNU(-devel) ELPA
soonish if all goes well.


        Stefan