Re: Namespaces - summary, conclusion

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

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 <philippe.vaucher@gmail.com>
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
>
>

[-- Attachment #2: Type: text/html, Size: 5381 bytes --]