emacs-devel
[Top][All Lists]
Advanced

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

Re: Adding new packages to NonGNU ELPA


From: Bozhidar Batsov
Subject: Re: Adding new packages to NonGNU ELPA
Date: Wed, 25 Aug 2021 18:49:09 +0300
User-agent: Cyrus-JMAP/3.5.0-alpha0-1125-g685cec594c-fm-20210825.001-g685cec59

One of my hopes regarding NonGNU ELPA was that certain packages,
including dependencies could be effectively deprecated. Among these I
hoped to see packages such as a (but also s, f, ht, ...). My
understanding was that these were created to either compensate
deficiencies in the build-in functions provided by older versions of
Emacs. The other reason is that some people prefer a more functional
style of programming, that the usual stateful, imperative-ish Elisp
doesn't always provide.

I guess in the end of the day that mostly depends on the package maintainers. Some are quite attached to those utility libraries, even if I myself don't like them and I've always avoided them. But I happen to be the type of person who avoids external dependencies as much as possible in general. :-) It was actually me who added the most common functions from s.el to Emacs itself a few years ago. Probably something like this should be done for f.el as well at some point.

For CIDER one can follow the progress of removing a.el from parseclj here https://github.com/clojure-emacs/parseclj/pull/29 Some limitations of map.el are preventing this change from being wrapped up fully, though. Still, there are no showstoppers.  

On Wed, Aug 25, 2021, at 2:05 PM, Philip Kaludercic wrote:
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Here's the next batch of patches, I hope I got everything right. I've
> started with the simple packages and I'll continue with CIDER and its
> related packages, as they have a bunch of transitive deps I'll need to
> add to NonGNU ELPA as well (a, parseedn, parseclj).

One of my hopes regarding NonGNU ELPA was that certain packages,
including dependencies could be effectively deprecated. Among these I
hoped to see packages such as a (but also s, f, ht, ...). My
understanding was that these were created to either compensate
deficiencies in the build-in functions provided by older versions of
Emacs. The other reason is that some people prefer a more functional
style of programming, that the usual stateful, imperative-ish Elisp
doesn't always provide.

Regarding the first motivation, I think it is legitimate, because that
is how backwards compatibility can be maintained. It might therefore
make sense to provide a compatibility library-package to provide useful
but perhaps simplified/dummy definitions of new functions, macros and
variables added in newer versions of Emacs. That of course would only
make sense if there is any consensus that the community libraries
shouldn't be used.

-- 
Philip Kaludercic




reply via email to

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