On Tue, May 5, 2020 at 8:29 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> But it could be in a destructive rather than constructive way: having
> a separate "ELISP" package would reduce the impetus to impose a good
> naming structure within this package, which is what this thread is
> all about.

You can split it up, slowly. Or quickly if you pick a namespacing
technique that is backward compatible with the current naming
scheme. Tom Tromey's idea sounds nice, and it could be
enhanced, IMO.  Let's at least admit that if namespaces were here
right now it would be No Bad Thing. The s.el request that started
this whole thing would be trivially attended to, at least.

> >    João "who instantly regrets mentioning the manual cause I just say
> > unibyte-string there, too"
>
> Yup: `multybyte-string-p` is not even mentioned in the manual.

multybyte-string-p isn't :-) , but multibyte-string-p is:

in (elisp) Text Representations

 -- Function: multibyte-string-p string
     Return ‘t’ if STRING is a multibyte string, ‘nil’ otherwise.  This
     function also returns ‘nil’ if STRING is some object other than a
     string.

But OK. I've already said this one wouldn't bother me. It's just I've
seen big lists (10-20 long) of renames/aliases and those new names
would burden my mental namespace -- and my completion-based
discovery techniques (and Eli's C-h a techniques, to a lesser degree).