[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 20:31:19 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
On 06 Feb 2021, jao wrote:
On Fri, Feb 05 2021, Karl Fogel wrote:
On 05 Feb 2021, Jose A. Ortega Ruiz wrote: 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.
Oh, but "moving the binding of revert-buffer" is not what we're
discussing. We're discussing (or, well, /i/ was discussing,
perhaps i misunderstood) assigning a currently unbound command to
a currently unassigned key.
Sure, but my answer to your question is still the same answer.
I'm arguing that Emacs make explicit commitments about keeping
some keyspaces free in the default distribution, in order to favor
users who are likely to make long-term investments in custom
keybindings.
It already does this with `C-c LETTER', of course. I'm just
saying let's make the same commitment a few more places. The
justification for this would be to create more places where users
will feel safe to make finger-memory investments.
Every such decision (to move a default Emacs keybinding to
somewhere else) will cause me to diverge a bit further from
default Emacs,
Yes, i agree that /moving/ an already assigned binding to a
"free" key is a bad idea. I was thinking of creating new ones.
I hope it was clear, but just in case it wasn't: my paragraph was
talking about *me*, the user, moving a recently-changed default
Emacs keybinding to somewhere else, just in my Emacs, in order to
preserve a custom binding in its current place. And I was just
explaining why even though any user is free to do this, it still
has costs for that user, and therefore we should try to help users
not be in the position of facing that choice.
You stated elsewhere that you think Emacs should never replace an
existing default keybinding with a different default keybinding.
I don't know if we have that policy, but if we do, then the
problem I'm worried about would not exist, that's true.
[...]
Well, i gladly diverge in that sense, and occupy any existing
binding that i never use with a personal one that i use 10 times
an hour (or even once a day, or a week). And, at the same time,
i'd rather see (say) C-x r bound to a command that the emacs
maintainers find useful, than empty--on behalf of vanilla emacs
users without heavy customizations (which include, i suppose, a
majority of newbies).
This is a genuine difference of opinion, yes. There are good
arguments on both sides here, I think.
My argument has long been that Emacs should prioritize the needs
of investment-oriented users. That is, to make Emacs slightly
worse for the investment-oriented users in order to make it better
for those who are unlikely to invest is usually the wrong
decision.
You wrote "newbies" above, but I think it's important to
distinguish between two kinds of newbies: the investment-oriented
ones, and the ones who are unlikely to invest. Your assertion is
true for the latter kind, but not the former. Some newbies will
*eventually* be highly invested users who are looking in the
crowded keymap landscape for some free space to put their
customizations :-).
Yes, thank you. I hope i've also been able to clarify a bit my
(in some ways, opposite) perspective (BTW, for 3rd-party
libraries, my stance is quite different; i think they should
never define any top-level keybinding, and put instead all their
commands in a keymap with a configurable prefix, whose value
would be asked on first interactive use, informing the user of
what commands her prefix choice is overriding. but that's
wishful thinking :)).
Yes, you did succeed in clarifying, and I appreciate it!
Best regards,
-Karl
- Re: Concern about new binding., (continued)
- 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, 2021/02/05
- Re: [External] : Re: Concern about new binding., jao, 2021/02/05
- Re: [External] : Re: Concern about new binding.,
Karl Fogel <=
- 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
- Re: Concern about new binding., Juri Linkov, 2021/02/05
- Re: Concern about new binding., Lars Ingebrigtsen, 2021/02/06