Re: PROPOSAL: Repurpose one key and reserve it for third-party packages

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.02.2021 21:01, Gregory Heytings wrote:
> 
> [Re-attaching this to another thread.]
> 
>>
>> Freeing 'C-z' up, for example, won't help most authors anyway.
>>
> 
> Why not?  Could you perhaps elaborate?

In case it was not apparent from the preceding discussion: it's a 
contentious binding, and even if I was not using it myself, I should 
have been aware that a significant number of Emacs users already bind 
that key in their init scripts (to 'undo' or 'undo-tree-undo', I mean). 
Or use the default binding often, as some of the regulars here report.

As a package author, I would make an effort to choose a binding that is 
more likely to be unoccupied in all my users' configs. Or be, you know, 
free-able, which 'C-z' likely isn't.

>> I have some doubts that we'll be able to free up nice enough key 
>> bindings that third-party packages will all want to use.
>>
> 
> What would be, for you, a nice enough key binding?

Some examples:

- diff-hl adds some bindings under the 'C-x v' map because it is 
intended as an extension of VC.
- company doesn't add any global bindings, but has a number of them 
inside company-active-map (when completion is ongoing) and also 
recommends the user choosew a binding for `company-complete`. I use 
'C-/', personally.
- rspec-mode uses 'C-c ,' as the default keymap prefix but makes it 
customizable via a variable.
- robe uses a number of bindings reminiscent of SLIME. These days I 
should migrate some of them to the xref package, and the rest ('C-c C-d' 
most prominently) keep as-is. Could have migrated to Eldoc, but that one 
is moving in a weird direction lately.

>> And even if that happens, collisions between externally maintained 
>> packages can happen just as well. There is no foolproof solution.
>>
> 
> That's unavoidable, but still much better for newcomers than the current 
> situation.  And there are ways to handle such collisions, which should 
> be rare if the number of available keys is large enough, in a 
> user-friendly way.

FTR, I don't support the recent addition of bindings on 'C-x x', in part 
because those commands don't seem essential to me. But for the same 
reason I don't see a problem with any third-party mode continuing to use 
'C-x x' as its keymap prefix.