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

[조성빈 <pcr910303@icloud.com>]

> 2020. 5. 12. 오전 1:42, Alfred M. Szmidt <ams@gnu.org> 작성:
> 
> 
>> 
>> This is just a matter of following the good practises that already
>> exist in Emacs.  It would be a bad idea to start making a mess, and
>> then encouraging this mess to become larger.
> 
>   Posited on s.el being a mess, which neither it, nor dash.el is. They are
>   both nice APIs that are nice to use.
> 
> In isolation these libraries do not create a mess, and it was never
> claimed that they are so.  The issue is making them part of
> Emacs/ELPA, thus encouraging people to start using non-standard Emacs
> Lisp conventions in Emacs.  _That_ would be the mess.
> 
> I really urge people to carefully read what people have written to
> minimize these type of misunderstandings.
> 
>   I did manage to drop a dash.el dependency form one of my libraries and
>   replace it with seq.el. That worked because it was close to a drop
>   in. But people have already chosen to work with dash, or s, or f, even
>   though it means adding a dependency because they are nice.
> 
> Would you like to suggest which parts of those libraries are nice in
> your opinon so that they could maybe be added to Emacs, following
> normal Emacs conventions?

There was a long, long controversial thread about this. (And I think this thread is a branch of it?)

All of this discussion started about having some more string functions and renaming some of them so that people didn’t need to use s.el. 

FWIW, nobody asked to add it in Emacs core. The only request was to add it in ELPA, which looks like everybody has a different idea of what it is. (I thought of it as a blessed package repo, but apparently a lot of people here thinks that it’s an extension to Emacs.)