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

[Karl Fogel]

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