emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELPA: new package nano-agenda


From: Adam Porter
Subject: Re: ELPA: new package nano-agenda
Date: Mon, 18 Oct 2021 17:50:32 -0500

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]