unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
Date: Tue, 09 Feb 2021 23:06:08 +0100	[thread overview]
Message-ID: <871rdoj3qn.fsf@zoho.eu> (raw)
In-Reply-To: SA2PR10MB44740762D80C46278FCB4403F38E9@SA2PR10MB4474.namprd10.prod.outlook.com

Drew Adams wrote:

>>> But no effort is needed for keys not yet bound - zero,
>>> beyond documenting the fact.
>>
>> The effort, or the absence of effort, is not the important
>> point here.
>
> You're the one who brought up the "effort" needed by Emacs
> to carry out this or that proposed change. You claimed that
> your proposal needed less effort. I argued that it needs
> more effort (> zero).
>
> This was important enough that you brought it up. Now it's
> not important. OK.
>
>> The main point is freedom: give more freedom to both Emacs
>> and third- party libraries. And "documenting the fact that
>> keys not yet bound cannot be bound anymore" hinders Emacs'
>> freedom. I know, you also said that "exceptions would be
>> possible with the approval of maintainers", but that's
>> precisely what happened with the new "C-x x" key, and you
>> objected anyway.
>
> Maintainers decide. I accept that - that's their role,
> always, including on those occasions where I might disagree.
>
> The entire discussion was brought to emacs-devel - not by me
> - from a bug thread, where `C-x x' was taken over willy
> nilly, yes, over my objection.
>
> And the bug/enhancement request was much narrower.
> The decision was to bind a _global_ key by default.
> Gigantic overkill, for the narrow problem raised by the
> bug report.
>
> I agreed (in emacs-devel, when discussed there, and in the
> bug thread before that) that such wide decisions - wider
> than the bug thread - should preferably follow wider
> discussion in emacs-devel.
>
> Half of the discussion in emacs-devel was/is about this
> problem that some big, wide-ranging change gets made in
> a bug thread, without many eyes seeing it or minds
> discussing it. That's a problem (IMO - the maintainers
> disagree).
>
> Wrt the actual change made:
>
> I objected that, within the last year, first prefix key `C-x
> p' was taken over, so I changed my code to use `C-x x'
> instead, and now `C-x x' was also taken over. That's quite
> a bit to lose in a year. And both changes were made in bug
> threads - no discussion in emacs-devel.
>
> I objected to that, and I still object. It's not I who
> decide, and that's fine. But my opinion that this isn't
> a good change, and that such things should be discussed in
> emacs-devel, remains.
>
> I'm not so worried as you about Emacs's "freedom" to bind
> the keys it wants. Casting this as a question of "freedom"
> is alarmist and ridiculous, IMO. This is a question about
> what key-binding conventions we should have, nothing more.
>
>>> My proposal is to separate any and all such possible
>>> default key-binding _changes_ from the simple act of
>>> declaring the keys so far unbound by default to be
>>> reserved for 3rd-party code.
>> 
>> That just can't happen, it would be a arbitrary constraint
>> that would impair Emacs' evolution, it would mean that
>> hundreds of small or large potential improvements would not
>> be possible anymore.
>
> Not at all. It would mean that Emacs would try harder not to
> add new default key bindings. It's not trying hard enough
> now - that's the problem. IMO, it's gotten worse lately,
> when we can least afford it (available keys are scarcer and
> scarcer).
>
> I asked for other solutions to the problem (still asking).
> And the maintainer's reply was that there is no problem.
>
> Yes, you proposed another answer to the problem, and that's
> fine. It's not as good an answer as mine, IMO, but at least
> you offered something.
>
>>> I would welcome any such support, if that really is
>>> your intention.
>> 
>> FWIW, it was indeed really my intention. The proposal is an
>> attempt to find a reasonable middle ground that would give
>> as much freedom as possible to Emacs, as much freedom as
>> possible to third-party library developers, and without
>> changing users' habits too much.
>
> That's a good intention, though the ideas that this is about
> "freedom", and that Emacs needs more "freedom" to add
> default key bindings, are misguided, IMO.
>
> And as I said, by proposing to use a currently bound key for
> this you increase, not decrease, the contention and argument
> over which keys Emacs should "lose" to this, and you
> increase, not decrease, the need for users to change habits.

If only you could be passionate about it!

But seriously now, I thought people had just got a bit crazy
like they sometimes do, but reading this long post I realize
I missed something... What has happened? Can anyone summarize
it i one or to paragraphs instead of ~20?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal




  reply	other threads:[~2021-02-09 22:06 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 [this message]
2021-02-09 22:58                   ` Drew Adams
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=871rdoj3qn.fsf@zoho.eu \
    --to=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).