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

[Karl Fogel]

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