Re: Imports / inclusion of s.el into Emacs

[Philippe Vaucher]

> > multibyte-string-p -> multibyte-string-p
> > string-to-multibyte -> multibyte-from-string
> > string-as-multibyte -> multibyte-from-string-unsafe
> > set-buffer-multibyte -> buffer-set-multibyte
> > multibyte-char-to-unibyte -> multibyte-char-to-unibyte
>
> [1]
>
> Do you know what this would make to fine completion list
> I gave you?  It would make it suck.  So you, the "bit of an
> extremist" who "is annoyed by a little noise", are prepared to
> introduce  an unimaginable amount of it into my and other's
> workflows at the slightest difficulty and resistance to read
> a fine manual.  I like Emacs because it respects people's
> established workflows, and allows for programmers
> to build on it, so they can use whatever workflow they
> prefer.

I think I already acknowledged that point in
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00508.html
Which is why I don't think any of my renames proposal will be
accepted. Maybe one or two but so far I haven't found a single example
where everyone agreed. In the multibyte example I was just
illustrating how I think about things.


> Unfortunately, you're finding it a bit hard to support
> your -- absolutely legitimate, mind you -- ruby-esque
> ways.  But you should be working to have proper
> namespacing so you can work with a magnar-string.el
> or ruby-regexp.el library the way you feel more
> confortable.  That takes work, yes, but at least it's a
> win-win, not a lose-lose. If proper namespacing takes a lot
> of work, then work on a powerful completion tool. I can
> help you with that.  You're French, right? Imagine if
> Google  decided they'd to the complete works of Raymond
> Roussell from French to modern, easy-to-search, French.

Actually I'm swiss, from the french speaking part of Switzerland.
Funnily enough we think we speak a better french than the frenchs
themselves, given we say the more logical "seventy-five" instead of
"sixty-fifteen" like they do. Maybe that's why I think I know better
how to name things than the actual authors :-)

Anyway, at this point I'll make a "concrete proposal" like I was
asked, something very simple and hopefully very uncontroversial, but I
think the bikeshedding can stop. We obviously disagree how APIs should
be designed.

Basically I focus more on the advantages of putting the
discoverability/consistency inside the language itself instead of its
tools, while you focus more on how disruptive this approch will be and
how we could still get what I want with new tools instead of the
language.

I thought we had a golden opportunity to put s.el inside Emacs:

- The author is willing.
- The number of contributors is small, most of them already signed the
papers including the author.
- A lot of "github" Emacs users would see this as a good sign.

But I realise now that even if this was done, what would likely happen
is that s.el get stale because adding/modifying it is not as simple &
smooth as doing so on other platforms, and a new s.el will appear and
we can repeat what happened these past days in a few years.

On the topic of s.el inclusion here are my conclusions (please correct
me if they are wrong):

- I can try to suggest a few aliases, and maybe one or two will be
accepted, but certainly not a lot.
- I can try to suggest a few new functions, and maybe one or two will
be accepted.
- Whatever is introduced is likely to be "Emacsified" as not to look
too much like clojure.
- I can notify the author of s.el that only a tiny subset of s.el (if
any) is likely to be imported, but he should know he's very welcome to
put s.el on ELPA.

Kind regards,
Philippe