Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Wed, May 6, 2020 at 10:20 AM Philippe Vaucher
<address@hidden> wrote:
>
> >> Out of curiosity, say "real" namespaces land in Emacs, do you reckon
> >> we'd be able to agree on reasonably well-defined topics?
> >
> > Sure, I think so.  If they were here today, you could have
> > the s.el library under  the "modern-string" namespace
> > or "magnar-string" namespace or something like that. I don't
> > see it'd be contentious. In your library, you could then somehow
> > indicate you'd like to use the "magnar-string" namespace
> > and have access to what is now "magnar-string-empty-p"
> > under just "empty-p". Or maybe you'd prefer to indicate
> > you want to use the "magnar-string" namespace under
> > the "s-" local nickname.  Then you can type "s-empty-p"
> > as you're used to. Same thing with dash.el that so many
> > people like.
>
> Very interesting. To me it looks like we cannot agree on prefixes
> already... thus I infer that if namespaces would work, then the
> current disagreeing is about "any renames" more than disagreeing with
> the "prefix" (namespace) chosen. Putting things in namespace would not
> be seen as renames, because they can still get the "untouched" names
> experience.

Yes, I think so.  Today we can agree on a prefix by
choosing a long or unique enough name that everyone agrees
won't impact them.  That happens all the time.  But it's clear that
s.el and dash.el want to be (very) short-prefixed, by their very
nature, otherwise they lose their charm.  So namespaces are
a way to get that opt-in, instead of wholesale or indiscriminately.

My problem with renames or aliases  on "core" symbols
is like Richard's, I think.  It burdens my mental model and it
burdens my discovery techniques, which include C-h f and C-h a. So
my logic is: if we're going to do that in the name of a good and
discoverable library that also wants to be readily accessible,
we might as well work on ways to get to that objective in ways
that don't have those drawbacks _and_ kill the possibility
of that library.

My personal opinion on the s.el library, which isn't very positive,
doesn't matter here. It should not be excluded because of a
namespacing issue.

João