Re: not good proposal: "C-z <letter>" reserved for users

[Joost Kremers <joostkremers@fastmail.fm>]

On Thu, Feb 11 2021, Gregory Heytings wrote:
>>
>> Basically, I don't see a problem here that couldn't be solved much more 
>> easily by updating the keybinding conventions to say that external 
>> packages should not create any global bindings by default.
>
> IMO that would be the worst possible solution, and would be an extremely 
> negative signal towards third-party library developers.

Why? It's been my interpretation of the intent of the key binding conventions
and as a package maintainer I have never been bothered by it. In fact, I see it
as a courtesy to the users of my packages that I do not stomp on whatever key
bindings they may have set already.

So I guess this comes down to very different views we have about what
constitutes "user-friendly" in this particular case.

>  Do you remember 
> that Emacs is an _extensible_ editor? 

[I had a hostile reaction here to what I perceived to be a hostile remark from
you. If that was a reaction to something I said, I apologise.]

> Why shouldn't an extension package for a general-purpose editor (not 
> necessarily Emacs, think Atom or Sublime or...) change the user interface 
> of that editor when it is installed?

It depends on the change and the purpose of the package. Global key bindings are
a limited resource, which is why I'd expect 3rd-party packages of any editor to
be conservative about creating new ones. Same thing with the top-level menu,
especially if a package wants to add a new item that is permanently visible.
Adding a menu entry to an existing (sub)menu is fine, since they're more
flexible (they can scroll, for example), but there, too, I'd expect 3rd-party
packages to tread carefully (e.g., if you want to add a dozen new entries, then
maybe put them together in a new submenu).

For packages whose primary purpose is to change the user interface, it's
different, of course. An Emacs package that exists to change global key bindings
(evil comes to mind) are fine, because the user installs them for that purpose.
But I don't install Magit to change my UI.

Now, I've never used any other editor than Emacs (not seriously, anyway), but
when I look at screen casts of people using Atom or PyCharm or something,
they're clicking their way through the interface with skill and accuracy. If I
were such a user, I wouldn't want an external package to suddenly change my
menus for me, especially if part of the appeal of the editor I'm using is the
fact that I can modify and lay out the menus in exactly the way I like. (I don't
know if that's the case with Atom or Sublime or VSCode or any of the other
editors out there, because, as I said, I've never used them.)

>> Reserving keys for external packages means that Emacs needs some way to 
>> deal with conflicting external key bindings, which will inevitably 
>> arise.
>
> Yes, and this has been acknowledged from the outset.  It's a different 
> problem however, these are conflicts between external packages, not 
> between an external package and Emacs core or between an external package 
> and users' personal bindings.

I don't really see it as a different problem. To me it's immaterial whether
there's a conflict between Emacs and an external package, between two external
packages or between a user's bindings and an external package; they're all
conflicts caused by an external package creating a global key binding.

>  And, as you yourself say, these conflicts 
> can be handled by specific functions, in a user-friendly way.

Yes. But the argument isn't that conflicts will arise. The argument is that in
order to handle them properly, we need a system that is more complex than the
alternative. And, in my opinion, too complex for the problem at hand.

You obviously feel differently, which is fine. After all, in the end, what you
or I feel isn't all that important. Just two more data points for the Emacs
developers to make a decision.

-- 
Joost Kremers
Life has its moments