unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Emanuel Berg <moasenwood@zoho.eu>
Cc: "Help-Gnu-Emacs \(help-gnu-emacs@gnu.org\)" <help-gnu-emacs@gnu.org>
Subject: RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
Date: Tue, 9 Feb 2021 22:58:26 +0000	[thread overview]
Message-ID: <SA2PR10MB44748FFDED0D62F4D718BE78F38E9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <871rdoj3qn.fsf@zoho.eu>

> I realize I missed something... What has happened?
> Can anyone summarize it i one or to paragraphs
> instead of ~20?

Here's my summary (1-9).  Others might see it
differently.  And it's possible that I don't
remember some details perfectly.  Someone will
correct me if I'm mistaken somewhere.

1. Bug #46151, "Set revert-buffer-function in shell
   command output buffers", proposed binding a key for
   `revert-buffer' in shell command buffers (only).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151

2. A discussion in that bug thread led to discussion
   of whether Emacs needs a _global_ key binding for
   `revert-buffer'.

   My own opinion was this:

     Overall, my opinion is to NOT bind it by default.
     Yes, it's useful.

     But it's also easy to do with `M-x revert'.  (And
     then repeat that as a previous command, as needed.)

     And it has many existing bindings, for modes where
     it's used frequently.

   Some others agreed that we need no global binding
   for `revert-buffer'.  If interested, see the thread
   for the discussion.

3. The bug-thread discussion then went toward binding it
   to a global key under `C-x'.  My position was not only
   that we need no global binding for it, but that `C-x',
   in particular, should at this point be left alone.  I 
   explained that I already was forced to move from using 
   prefix key `C-x p' to `C-x x' etc.  I said:

     Users and 3rd-party libraries should really start to
     take precedence now, IMHO.  Emacs should try not to
     bind any more keys by default - starting with `C-x'.
     And certainly for things like `revert-buffer', which
     have survived for 35 years without a default binding.
     YAGNI.

4. Maintainer Lars bound `revert-buffer' globally to
   `C-x g', and closed the shell buffer bug.

5. User Ergus posted in emacs-devel about that,
   complaining that the question should have been
   discussed in emacs-devel (the consequences are
   wider than just shell buffers).

6. A long discussion ensued in emacs-devel.  In
   that discussion I agreed that when a bug-thread
   discussion moves beyond the bug to wider questions
   with wide consequences it should preferably be
   moved to emacs-devel.

   And I repeated my disagreement about globally
   binding `revert-buffer', and in particular about
   binding it to something on `C-x'.  I repeated my 
   suggestion that Emacs desist for a while from
   binding any new keys - at least that it try and
   have that as a convention/goal, and that we
   reserve those remaining keys for use by 3rd-party
   libraries.  Gregory proposed instead that we
   just reserve one key under `C-x', for use as a
   prefix key by 3rd-party code.

7. The main maintainer, Eli, disagreed that questions
   wider than a bug's subject should generally be
   brought to emacs-devel, and he supported the
   decision to bind `revert-buffer' to `C-x g'.

   Other users spoke up complaining about that key, 
   suggesting other keys for it, and so on.  Each
   time a key was suggested someone invariably
   complained.  (Not I - my disagreement is more
   general - I would no global key to be bound to
   it by default.)

8. There was also discussion about the problem of
   people in emacs-devel not being aware of the
   details of this or that bug report, IOW, _how_
   to make the wider group be aware of some bug
   discussion that's grown wider and should maybe
   be moved to emacs-devel.

9. That's pretty much where we are, I think.  Again,
   I may have forgotten something here or there.  I
   haven't intentionally left anything out.

___

Here's the summary of my position, from that bug thread:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151#88

And here's a longer post of mine about the various
questions - a summary, but not short.

https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00312.html



  reply	other threads:[~2021-02-09 22:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 10:02 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
2021-02-08 16:41 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-08 22:01 ` Francis Belliveau
2021-02-09  0:05   ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09  8:36     ` "Windows" key [was: Repurpose one key and reserve it for third-party] packages tomas
2021-02-10 22:54     ` PROPOSAL: Repurpose one key and reserve it for third-party packages Francis Belliveau
2021-02-09  6:31 ` Jean Louis
2021-02-09  9:13   ` Gregory Heytings
2021-02-10 11:17     ` Jean Louis
2021-02-09 17:13   ` [External] : " Drew Adams
2021-02-09 17:49     ` Gregory Heytings
2021-02-09 18:12       ` Drew Adams
2021-02-09 19:23         ` Gregory Heytings
2021-02-09 20:52           ` [External] : " Drew Adams
2021-02-09 21:15             ` Gregory Heytings
2021-02-09 21:47               ` [External] : " Drew Adams
2021-02-09 22:06                 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-09 22:58                   ` Drew Adams [this message]
2021-02-09 23:23                     ` Drew Adams
2021-02-09 23:48                     ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 11:07                 ` Gregory Heytings
2021-02-10  9:05               ` Robert Thorpe
2021-02-10 14:42                 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-02-10 14:59                   ` Gregory Heytings
2021-02-10 11:33       ` [External] : " Jean Louis
2021-02-10 11:41         ` Thibaut Verron
2021-02-10 15:29           ` Eli Zaretskii
2021-02-10 11:30     ` Jean Louis
2021-02-09  8:13 ` Marcin Borkowski
2021-02-09  9:13   ` Gregory Heytings
     [not found] <7ef75c33936136eb3a20@heytings.org>
     [not found] ` <8735y56naf.fsf@posteo.net>
     [not found]   ` <8ed9b43502ae9a36b057@heytings.org>
     [not found]     ` <87tuqk6d9d.fsf@posteo.net>
     [not found]       ` <3966473cc1ab9f104724@heytings.org>
2021-02-10 23:35         ` Philip K.
2021-02-11  8:45           ` Gregory Heytings
2021-02-11 13:53             ` Philip K.
2021-02-11 15:59               ` Gregory Heytings
2021-02-11 16:59                 ` [External] : " Drew Adams
2021-02-11 16:58             ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SA2PR10MB44748FFDED0D62F4D718BE78F38E9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=moasenwood@zoho.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).