emacs-devel
[Top][All Lists]
Advanced

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

Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]


From: Stefan Monnier
Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
Date: Sat, 09 May 2020 09:59:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>    - As far as I know you are the only one who objected strongly against
>    s.el in ELPA (others please voice your opinion if you think like
>    Richard). 
>
> I as a Emacs user would think s.el is a bad addition to ELPA -- it
> doesn't add anything special,

It is used by hundreds of packages.  So as long as it's not in GNU ELPA,
none of those hundreds of packages can be even considered for inclusion
into GNU ELPA.

That's the special that it adds.

> and makes code harder to read if people use such constructs in the
> form that they are now, encouraging people to use s-titleize instead
> of capitalize is going backwards, not forwards.

I highly doubt including it in GNU ELPA will make much difference w.r.t
encouraging people to use it.

> I haven't seen anyone objecting from adding some of the more
> complicated functions and making them follow a more Emacs-y form, or
> even on a case-by-case basis renaming some string functions to make
> more sense. 

That's a completely different discussion (which affects Emacs's core
but doesn't help clear the obstacles for inclusion of other packages
into GNU ELPA).

> So why this forceful insistance of adding a s.el?  Why not try to make
> Emacs as a whole better by suggesting the better parts of s.el that
> can be added to Emacs, or finding functions that could be renamed?

Whether s.el is included into GNU ELPA has no bearing on whether or not
we'll want to include some of its ideas into Emacs's core string functions.


        Stefan




reply via email to

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