Re: [External] : Re: Concern about new binding.

[jao <jao@gnu.org>]

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.

> 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.

> 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.

I think that especially in that scenario (no .emacs available) i'd
prefer this new command to be bound somewhere, be it reserved or not,
because without your .emacs and without allowing emacs to occupy it,
those "free" bindings won't be available to anyone.

> 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.

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).

> 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.

Yes, replacing is bad, we agree on that.  (I hope i'm right and
replacing was never on the table).

> 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?

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 :)).

Cheers,
jao
-- 
He is a hard man who is only just, and a sad one who is only
wise. -Voltaire, philosopher (1694-1778)