[Top][All Lists]

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

Re: Imports / inclusion of s.el into Emacs

From: Stefan Monnier
Subject: Re: Imports / inclusion of s.el into Emacs
Date: Fri, 01 May 2020 14:09:43 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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).


> 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).

reply via email to

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