[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for thir
From: |
Emanuel Berg |
Subject: |
Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages |
Date: |
Tue, 09 Feb 2021 23:06:08 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, (continued)
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Jean Louis, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages,
Emanuel Berg <=
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- RE: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Drew Adams, 2021/02/09
- Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Emanuel Berg, 2021/02/09
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/10
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Robert Thorpe, 2021/02/10
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Emanuel Berg, 2021/02/10
- Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Gregory Heytings, 2021/02/10
- Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Jean Louis, 2021/02/10
- Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Thibaut Verron, 2021/02/10
- Re: [External] : Re: PROPOSAL: Repurpose one key and reserve it for third-party packages, Eli Zaretskii, 2021/02/10