[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: Concern about new binding.
From: |
Karl Fogel |
Subject: |
Re: [External] : Re: Concern about new binding. |
Date: |
Fri, 05 Feb 2021 17:38:33 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
On 05 Feb 2021, Jose A. Ortega Ruiz wrote:
I honestly don't understand this reasoning. Please bear with me.
Say today you have C-x g bound to a favourite command of yours.
How would emacs 28 binding it by default to revert-buffer
interfere with your emacs usage? Would that limit you in any
way? Chances are you won't even notice (if you're setting it
unconditionally in your init.el). By contrast, by our
prohibiting binding any subset of keys to anything at all, users
who don't (or can't) customize their emacses will never have any
use for those "free" bindings, and will never have a more
convenient way of accessing, say, revert-buffer. How are we
making user's lives more convenient by prohibiting to emacs
maintainers (or library writers, for that matter) to use any
currently unbound slot for a new binding?
Ah, I can answer this. It has to do with protecting investment.
When I custom-bind a command to a key, I am making an investment
in finger memory. For example, I have `revert-buffer' on `C-c r'
(because I use `revert-buffer' a lot), and I chose `C-c r'
precisely because it was in the reserved space for user-chosen
keybindings. That way I could be sure Emacs would never bind some
other useful new function there.
Imagine if Emacs *were* to bind some other useful new function
there by default. Then I would face a hard choice: give up my
finger memory for `revert-buffer' (by moving my binding for it to
somewhere else), or custom-bind Emacs's new useful function to
some key different than where Emacs wanted to put it.
Neither option is attractive. The reason why the former option is
bad is obvious. But the reason why the latter option is bad is
maybe a little bit more subtle:
Every such decision (to move a default Emacs keybinding to
somewhere else) will cause me to diverge a bit further from
default Emacs, and that divergence has overhead costs. For
example, when teaching others or talking about Emacs with them,
now my Emacs's default bindings are slightly different from
theirs, which will cause confusion. Or sometimes I have to
operate temporarily on a remote machine where my .emacs isn't
available. Or I'm reading someone's post on emacs-devel and they
talk about invoking a command by naming the keystroke they used,
and I have to figure out what command they meant. Etc.
So this is why I stopped overriding keybindings in Emacs's default
space years ago. Now I (mostly) limit myself to the `C-c LETTER'
universe, and in some cases made prefix maps there.
I wouldn't want to conditionally bind a custom function to 'C-x g'
even when the binding I am replacing is one I don't care about
(imagine, for the sake of discussion, that I don't care about
`revert-buffer'). First of all, divergence has inherent costs as
explained above. Second, Emacs might some day replace the binding
that I don't care about with one that I like, and then I would
face the choice where if I want to make a new finger-memory in the
default keyspace, I would have to change an existing
finger-memory.
Whereas if Emacs promises never to bind something I might care
about on a key, then I'm free to make finger-memory investments in
that key, secure in the knowledge that the only potential source
of future hard choices will be me (well, me and maybe some
third-party package maintainers), not Emacs itself.
Does that explain better why I want Emacs to declare that it will
never use certain convenient and currently-empty keybindings by
default?
Best regards,
-Karl
- Re: Concern about new binding., (continued)
- Re: Concern about new binding., Kévin Le Gouguec, 2021/02/04
- Re: Concern about new binding., Thibaut Verron, 2021/02/04
- Re: Concern about new binding., Kévin Le Gouguec, 2021/02/04
- Re: Concern about new binding., Jean Louis, 2021/02/12
- Re: Concern about new binding., Kévin Le Gouguec, 2021/02/12
- Re: Concern about new binding., Gregory Heytings, 2021/02/04
- Re: Concern about new binding., Lars Ingebrigtsen, 2021/02/04
- RE: [External] : Re: Concern about new binding., Drew Adams, 2021/02/04
- Re: [External] : Re: Concern about new binding., Karl Fogel, 2021/02/04
- Re: [External] : Re: Concern about new binding., Jose A. Ortega Ruiz, 2021/02/05
- Re: [External] : Re: Concern about new binding.,
Karl Fogel <=
- Re: [External] : Re: Concern about new binding., jao, 2021/02/05
- Re: [External] : Re: Concern about new binding., Karl Fogel, 2021/02/05
- Re: [External] : Re: Concern about new binding., Jean Louis, 2021/02/12
- Re: [External] : Re: Concern about new binding., Dmitry Gutov, 2021/02/12
- RE: [External] : Re: Concern about new binding., Drew Adams, 2021/02/05
- Re: [External] : Re: Concern about new binding., Jean Louis, 2021/02/12
- Re: [External] : Re: Concern about new binding., Thibaut Verron, 2021/02/12
- Re: Concern about new binding., Juri Linkov, 2021/02/04
- Re: Concern about new binding., Lars Ingebrigtsen, 2021/02/05
- Re: Concern about new binding., Thibaut Verron, 2021/02/05