Re: Imports / inclusion of s.el into Emacs

[Phillip Lord]

João Távora <address@hidden> writes:

> On Fri, May 1, 2020 at 7:09 PM Stefan Monnier <address@hidden> wrote:
>>
>> > 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.
>
> Well none of those users of s.el are in GNU Elpa, right? They could
> trivially rename to use cjstring.el, or string.el.
>
> To be clear, I don't oppose the inclusion of those functions/macros
> especially if they really are advantageous (but are they really?).  What
> I really don't like about this and the dash.el library is that it takes up
> such a prominent place in the shared namespace, because of the
> very short  prefix.  Perhaps this argument is a bit reactionary, but then
> again s.el seems a bit /arriviste/ in that regard (likely unintentionally).
> If we had a package system, ideally one with local nicknames,
> this would all be moot, I think.

s.el is a big short, and dash even more so. But, to be honest, I prefer
dash over seq.el because it is short. It's double dash macros are also
really nice.

Obviously, there is a potential for disaster here, but I would argue
that if this was going to happen it would have already. Of the top of my
head, there is dash, s.el, f.el (for files), kv (for key value).

If emacs had a namespace prefix policy, which it doesn't, I would
reserve one letter and maybe two letter prefixes for nice APIs for
common things.

We'd still have a problem if Emacs had full namespaces right? Packages
always hog the high value namespace.

Phil