From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Namespaces - summary, conclusion Date: Mon, 4 May 2020 16:40:25 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000ebc2f705a4db0e6a" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="71849"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 01:55:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVkwG-000IYy-2F for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 01:55:56 +0200 Original-Received: from localhost ([::1]:41416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVkwF-0004r7-3F for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 19:55:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVkhd-0005ij-14 for emacs-devel@gnu.org; Mon, 04 May 2020 19:40:49 -0400 Original-Received: from mail-yb1-xb33.google.com ([2607:f8b0:4864:20::b33]:34231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVkhV-0005QK-Ik for emacs-devel@gnu.org; Mon, 04 May 2020 19:40:43 -0400 Original-Received: by mail-yb1-xb33.google.com with SMTP id q206so344233ybg.1 for ; Mon, 04 May 2020 16:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y/v06gEbn98t4HqwnmGrdLCO1eh4xdG02qp2WgtQsIE=; b=FKMpakPNNlMhDwu55XIB1u7PBxU+7Bv4OIZCtC002NEWu1jTE/Zp8VaB+4u725/+r+ dlgwW/9J+IesdFSoA3HxMq7BIZ86H5+N0s5yagTAZPitRNuqs3QjfJg7P+dWNO+9VetR hp8OTgHvBuBob9JhP+hGsFhbmzMNCIhqDPa1laKgoDVlZla2RawZPcyKlCFjlb36lFzc Tk3LcvOXJt8HV9Ttv6aPBKsDMSS0mHfs1iV5VvHoOKMQ5G5ImmKNiKIzNqPMbMJWqGPP ISUM2hGdjawrqfFonwsOsnoNeTFbexTYsTUKcoXv+FGiVjfCysH+zs3RE1MI8kQyt/5o Gfeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y/v06gEbn98t4HqwnmGrdLCO1eh4xdG02qp2WgtQsIE=; b=g1f3M3p2ZTNb9qonOmEYBo4GCidJnj5gWBUIWjoGwYWBqQoqeGV2TGpxe575e0DTjs UoZ3UDoRqcXklDKRCbAqxd/2JGJAyYMgW5lmcEuDAJVpAFWtBrpOv7KbQDIu7SnxKM52 DlFzZKmCb+FCuQgUZUf6IfE7aWvnPBU/5jPuYiH+5Z3N9dUXXfXfuT59inSf9z4V0Xpz i+DXBgus6bXxkHl/SrQ69wWR0pr6GcrWYUgfYI0yq6VxCqYanaBmFrfrg9FxbNYAmyoU pZIX/XTUMqDykdlRZ7ohTEs4OVO1+dNFhclr6UFBWqLnggl57xeZbxhHiymeHlEon9Y6 RX2w== X-Gm-Message-State: AGi0PubBzuSOK7eIIMGnEzvWlFVENrm9ckLRkEzTb4HcnO8j6PmEf5GV KHdPyRB9v44+k3zEv4jrkC1DMLGhLp1ok6zq6Jk= X-Google-Smtp-Source: APiQypKSwdO2Lw6EIpBETeOpBxHLfxnyXYUx/1tQSLUmRgGicEICRQG+oKDHa72j0ynUQvnCkZB3gVBOpYReBB4tGUE= X-Received: by 2002:a25:d8c1:: with SMTP id p184mr540778ybg.56.1588635638676; Mon, 04 May 2020 16:40:38 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b33; envelope-from=yandros@gmail.com; helo=mail-yb1-xb33.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248919 Archived-At: --000000000000ebc2f705a4db0e6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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=C3=A3o 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 ". > - 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 > > --000000000000ebc2f705a4db0e6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As long as we're still talking about summary & con= clusion, I think that you left out an important likely=C2=A0outcome: People= outside of the emacs core continue to build more "language cleanup/im= provement" libraries. My evidence is roughly "proof by existence&= quot;, 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 (smal= l sample size, biased observer, etc.). Supporting evidence is that such sys= tems are common in popular current languages (to my knowledge, JavaScript i= tself has between a couple and a dozen, depending on how you count).=C2=A0<= div>
While this isn't what I would personally consider th= e best outcome for emacs as a whole, it's probably not terrible. It see= ms to me that the way to optimise this world for emacs-devel is to try to h= elp 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 wid= ening dependency=C2=A0on MELPA" for future elisp code. (As a hypotheti= cal example, I could imagine a world where a Spacemacs successor both becom= es the "baseline emacs" for a generation of programmers and requi= res 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 &= lt;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<= br> 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 t= he
experience of those who like to search the manual "the classic way&quo= t;
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 "str= ing-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 histor= y,
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=C3=A3o 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/ema= cs/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>&q= uot;.
- 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 &q= uot;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

--000000000000ebc2f705a4db0e6a--