Re: Namespaces - summary, conclusion

[chad]

As long as we're still talking about summary & conclusion, I think that you left out an important likely outcome: People outside of the emacs core continue to build more "language cleanup/improvement" libraries. My evidence is roughly "proof by existence", in particular because what started with dash.el and perhaps cl{,-lib}.el has continued to expand over time with things like s.el and f.el (small sample size, biased observer, etc.). Supporting evidence is that such systems are common in popular current languages (to my knowledge, _javascript_ itself has between a couple and a dozen, depending on how you count). 

While this isn't what I would personally consider the best outcome for emacs as a whole, it's probably not terrible. It seems to me that the way to optimise this world for emacs-devel is to try to help any major examples get added to GNU ELPA, because the default/bad case seems to something like "add them to MELPA, use them, and create a widening dependency on MELPA" for future elisp code. (As a hypothetical example, I could imagine a world where a Spacemacs successor both becomes the "baseline emacs" for a generation of programmers and requires code that's available only via MELPA or github.)

I bring this up to encourage others to join the effort to get MELPA packages available on GNU ELPA.

Thanks,

~Chad

On Mon, May 4, 2020 at 2:27 AM Philippe Vaucher <address@hidden> wrote:

Hello,

I think for my part the amount of bikeshedding done was enough now and
I can come to some conclusions.

The proposal of aliasing or renaming Elisp functions that some of us
feel inadequately named/grouped got mostly a strong resistance by what
can be considered iconic figures of this community. I think that
cannot be taken lightly.

Here's a non exhaustive list of the counter-arguments, roughly ordered
how I feel are the best arguments to the not-so-relevant but
interesting:

- Adding new aliases, while improving the experience of those who like
to do an exact search for the regexp "^domain-.*", will degrade the
experience of those who like to search the manual "the classic way"
using "C-h d" or "C-h a".
- Adding new aliases or renaming functions might confuse the users
that are used to the current names. For example they might not
immediately understand that "re-search-in-string" means "string-match"
and have to look it up, wasting time.
- Adding new aliases increases the memory usage, the size of the
manual, and the amount of things to maintain.
- Emacs Lisp is fundamentaly a language where all concepts intermix
and thus is chaotic by nature, trying to organize it into categories
is against history and does not make sense.
- Even if we agree not to even touch the function name other than
adding a prefix (e.g `keep-lines` becoming `buffer-keep-lines`),
people will disagree on which prefix to use or about the genericity of
a function making it unprefixable, or that's it's a crime to history,
and thus consensus will be impossible to attain for almost every
proposed function.

Given this is more or less the position held by Alan, Eli, Richard,
Drew and João I think the chances of seeing new aliases is close to 0.
Until now every one of the proposed aliases (in string- or regexp-)
were rejected for arguably good reasons but the message is pretty
clear, I think aliases in Emacs core are a dead end (for now, that
might change later) and will only live in libraries in MELPA (or ELPA
is authors care).

So, the altenatives proposed are, ordered by chances of seeing it happening:

- Not rename anything, write some completion function that first
completing-read one of the section at
https://www.gnu.org/software/emacs/manual/html_node/elisp/index.html,
then using tricks to collect all function names there completing-read
that list of functions. Might be bound to a new "C-h <somekey>".
- Improve the sorting algorithm so somehow the function names
associated with a topic are automatically but to the top when you
search one of the "obvious" keywords like "alist" or "regexp". The
path toward that solution is pretty unclear to me, feel free to expand
on it.
- Add namespaces to Emacs Lisp.

Then there are other discussions going on, like the manual not
offering a "tutorial view" with highlighted examples, but I think
these are other discussions and should be discussed on their own.

Kind regards,
Philippe