ELPA: new package nano-agenda

ELPA: new package nano-agenda

[Nicolas P. Rougier (inria)]

Dear all,

I would like to submit a new package to ELPA which is a minimal 
non-intrusive view of org-agenda files. It displays a calendar 
view of current month (or the month corresponding to the current 
selected date) alongside a view of the daily agenda (timestamped) 
entries. The agenda can be navigated using arrows keys and killed 
using "q" or "return".

The sources are hosted at https://github.com/rougier/nano-agenda 
and the README displays what it looks like. I find it quite 
convenient for my own use but maybe it's too specific for ELPA.

Best,
Nicolas.

Re: ELPA: new package nano-agenda

[Philip Kaludercic]

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> The sources are hosted at https://github.com/rougier/nano-agenda and
> the README displays what it looks like. I find it quite convenient for
> my own use but maybe it's too specific for ELPA.

It seems you are using ts.el, which isn't on ELPA, and additionally depends
on s.el that also (famously) isn't on ELPA.

That being said, ts seems to only have a weak dependency on s (two
usages of s-join), so maybe ts could be added to ELPA -- in one form or
another -- as it seems to have a few useful improvements over the
default time and duration functions.

Otherwise, I don't see any grave issues from quickly skimming over the
code.

-- 
	Philip Kaludercic

Re: ELPA: new package nano-agenda

[Nicolas P. Rougier (inria)]

Philip Kaludercic <philipk@posteo.net> writes:

> It seems you are using ts.el, which isn't on ELPA, and 
> additionally depends
> on s.el that also (famously) isn't on ELPA.
>
> That being said, ts seems to only have a weak dependency on s 
> (two
> usages of s-join), so maybe ts could be added to ELPA -- in one 
> form or
> another -- as it seems to have a few useful improvements over 
> the
> default time and duration functions.

Thanks for the review, I didn't pay attention to this point 
actually. I confirm than ts would be a very nice addition to ELPA 
since it really simplifies time management for user and comes with 
a very clean API. I guess only Adam Porter can answer if he want 
to add it to ELPA or not. Should I try to remove the dependency in 
the meantime?

Nicolas

Re: ELPA: new package nano-agenda

[Philip Kaludercic]

"Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> It seems you are using ts.el, which isn't on ELPA, and additionally
>> depends
>> on s.el that also (famously) isn't on ELPA.
>>
>> That being said, ts seems to only have a weak dependency on s (two
>> usages of s-join), so maybe ts could be added to ELPA -- in one form
>> or
>> another -- as it seems to have a few useful improvements over the
>> default time and duration functions.
>
> Thanks for the review, I didn't pay attention to this point
> actually. I confirm than ts would be a very nice addition to ELPA
> since it really simplifies time management for user and comes with a
> very clean API. I guess only Adam Porter can answer if he want to add
> it to ELPA or not. 

As he is the only major contributor, this might be worth considering.
I've Cc'ed Adam to see what he thinks.

What might be an issue is if the "ts-" namespace is considered to be
"too valuable", as was the issue with "s-" and "f-". The maintainers
would have to decide on that, I can only speculate.

> Should I try to remove the dependency in the meantime?

Personally, I'd wait to see.

-- 
	Philip Kaludercic

Re: ELPA: new package nano-agenda

[Adam Porter]

Hi Philip, Nicolas, et al,

On Tue, Oct 12, 2021 at 2:41 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> "Nicolas P. Rougier (inria)" <nicolas.rougier@inria.fr> writes:
>
> > Philip Kaludercic <philipk@posteo.net> writes:
> >
> >> It seems you are using ts.el, which isn't on ELPA, and additionally
> >> depends
> >> on s.el that also (famously) isn't on ELPA.
> >>
> >> That being said, ts seems to only have a weak dependency on s (two
> >> usages of s-join), so maybe ts could be added to ELPA -- in one form
> >> or
> >> another -- as it seems to have a few useful improvements over the
> >> default time and duration functions.
> >
> > Thanks for the review, I didn't pay attention to this point
> > actually. I confirm than ts would be a very nice addition to ELPA
> > since it really simplifies time management for user and comes with a
> > very clean API. I guess only Adam Porter can answer if he want to add
> > it to ELPA or not.
>
> As he is the only major contributor, this might be worth considering.
> I've Cc'ed Adam to see what he thinks.

Yes, I'd be glad to have ts.el in GNU ELPA.

And I'd be glad to remove the dependency on s.el to facilitate that.

The only potential issue that I can see is that it currently emits
extra warnings at load time (or is it compile time?  I forget...) on
Emacs 28 due to more strict checking in the byte compiler.  The
warnings are harmless, and everything works correctly in spite of
them.  The last time I tried to find the cause of them, I wasn't
successful despite some effort.  I don't know if that would or should
keep it out of GNU ELPA; I would guess that it wouldn't, and that the
warnings can always be fixed or worked around later.

> What might be an issue is if the "ts-" namespace is considered to be
> "too valuable", as was the issue with "s-" and "f-". The maintainers
> would have to decide on that, I can only speculate.

I hope that wouldn't be the case.  In fact, I've already "defended"
the "ts-" prefix against other packages.  (That sounds aggressive or
confrontational, which I don't intend, but I'm not sure how else to
put it.  Actually, the maintainer of the elisp-tree-sitter repo,
Tuấn-Anh Nguyễn (@ubolonton), was very kind to rename his package's
prefix to `tsc-` to avoid conflicts when I asked him last year.  See
https://github.com/emacs-tree-sitter/elisp-tree-sitter/issues/35 )
And it's already used as a dependency in several other Elisp packages.

-- 
Thanks,
Adam

Re: ELPA: new package nano-agenda

[Stefan Monnier]

> Yes, I'd be glad to have ts.el in GNU ELPA.

That'd be nice.

> And I'd be glad to remove the dependency on s.el to facilitate that.

Yes, that'd be necessary before we can add it to GNU ELPA.

> The only potential issue that I can see is that it currently emits
> extra warnings at load time (or is it compile time?  I forget...) on
> Emacs 28 due to more strict checking in the byte compiler.

That's fine (code doesn't have to be bug-free, luckily, otherwise not
only GNU ELPA would be empty, but Emacs wouldn't exist either).

>> What might be an issue is if the "ts-" namespace is considered to be
>> "too valuable", as was the issue with "s-" and "f-". The maintainers
>> would have to decide on that, I can only speculate.

two-letter (well, 3 if you count the dash) prefixes are fine, thanks
(we have loads of them).


        Stefan

Re: ELPA: new package nano-agenda

[Joost Kremers]

On Tue, Oct 12 2021, Nicolas P. Rougier (inria) wrote:
> I would like to submit a new package to ELPA which is a minimal non-intrusive
> view of org-agenda files. It displays a calendar view of current month (or the
> month corresponding to the current selected date) alongside a view of the daily
> agenda (timestamped) entries. The agenda can be navigated using arrows keys and
> killed using "q" or "return".

I would suggest adding an autoload cookie to the main entry point `nano-agenda`.
That way, after installing the package, you don't have to `require` it first,
you can just do `M-x nano-agenda`.

-- 
Joost Kremers
Life has its moments

Re: ELPA: new package nano-agenda

[Nicolas P. Rougier (inria)]

Thanks, I've added it.

Nicolas


Joost Kremers <joostkremers@fastmail.fm> writes:

> On Tue, Oct 12 2021, Nicolas P. Rougier (inria) wrote:
>> I would like to submit a new package to ELPA which is a minimal 
>> non-intrusive
>> view of org-agenda files. It displays a calendar view of 
>> current month (or the
>> month corresponding to the current selected date) alongside a 
>> view of the daily
>> agenda (timestamped) entries. The agenda can be navigated using 
>> arrows keys and
>> killed using "q" or "return".
>
> I would suggest adding an autoload cookie to the main entry 
> point `nano-agenda`.
> That way, after installing the package, you don't have to 
> `require` it first,
> you can just do `M-x nano-agenda`.

Re: ELPA: new package nano-agenda

[Philip Kaludercic]

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

>>> What might be an issue is if the "ts-" namespace is considered to be
>>> "too valuable", as was the issue with "s-" and "f-". The maintainers
>>> would have to decide on that, I can only speculate.
>
> two-letter (well, 3 if you count the dash) prefixes are fine, thanks
> (we have loads of them).

Really? When I run 

        (seq-count
         (lambda (ent)
           (<= (length (symbol-name (car ent))) 2))
         package-archive-contents)

all I get is one result (xr).

-- 
	Philip Kaludercic

Re: ELPA: new package nano-agenda

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> all I get is one result (xr).

~/wip/emacs $ find -name '??.el' | wc -l
      28

Re: ELPA: new package nano-agenda

[Philip Kaludercic]

Stefan Kangas <stefan@marxist.se> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> all I get is one result (xr).
>
> ~/wip/emacs $ find -name '??.el' | wc -l
>       28

Ah, the core has more, but even then a number are obsolete (cl, gs, vi),
some are autogenerated (PY, QJ, SW) and a number are part of specific
packages (org has ob, oc, ol, ox; cedet as db, fw, ia, sb, el). The only
real two packages names are bs, js and vc (if you include Elisp
libraries, then gv, pp and rx would be included too).

The other question with ts is should the missing functionality be added
directly to Emacs itself?

Re: ELPA: new package nano-agenda

[Philip Kaludercic]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefan@marxist.se> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> all I get is one result (xr).
>>
>> ~/wip/emacs $ find -name '??.el' | wc -l
>>       28
>
> Ah, the core has more, but even then a number are obsolete (cl, gs, vi),
> some are autogenerated (PY, QJ, SW) and a number are part of specific
> packages (org has ob, oc, ol, ox; cedet as db, fw, ia, sb, el). The only
> real two packages names are bs, js and vc (if you include Elisp
> libraries, then gv, pp and rx would be included too).
>
> The other question with ts is should the missing functionality be added
> directly to Emacs itself?

Either way, something should be done. ts.el should be added or
nano-agenda  should remove the (silent) dependency, because in it's
current state it breaks for anyone who doesn't install ts manually.

-- 
	Philip Kaludercic