help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
Date: Mon, 15 Feb 2021 21:55:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]