Re: Imports / inclusion of s.el into Emacs

[Stefan Monnier]

> Just wanted to voice my support for exactly the points that Dmitry makes.
> And if we do add it to Elpa, can we give it a slightly longer prefix? Like
> 'cljstr`?

I don't think renaming it will fly.  We should definitely add it to GNU
ELPA because it's used by many other Elisp packages.  But renaming would
be self-defeating some all those packages won't want to go through
the renaming.

But for Emacs itself, we could probably rename some existing
functions to use the `string-` prefix and maybe incorporate some ideas
from s.el (I haven't looked very much into it, so I have no idea how
much there is to incorporate, but I assume there are some good ideas).


        Stefan


> On Fri, May 1, 2020, 18:21 Dmitry Gutov <address@hidden> wrote:
>
>> On 01.05.2020 17:56, Philippe Vaucher wrote:
>> > Following our discussion about namespace I think it's time to start with
>> > something concrete where most people are agreeing already
>>
>> FWIW, I made a couple of other suggestions.
>>
>> As far as s.el goes, I suppose it might be a good thing to add it to
>> ELPA for those who like it.
>>
>> I'm not completely sold on its contents for the core, however: a lot of
>> it looks like a compatibility layer for Clojure's familiarity's sake,
>> with very thin wrappers (which basically just add the cost of function
>> invocation).
>>
>> Examples:
>>
>> 1. s-prepend/s-append: trivially replaced by 'concat'.
>>
>> 2. s-trim: string-trim is already in subr-x.
>>
>> 3. s-split: basically delegates to split-string, but wraps it in
>> save-match-data (which is generally against our guidelines for its use).
>>
>>