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

[Robert Thorpe]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.02.2021 09:37, Robert Thorpe wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
...
>> Yes.  But I don't think that solves the problems that Gregory Heyting
>> and Drew Adams are talking about.
>> 
>> Firstly, it can't do anything about changes in keybindings in future
>> Emacs versions.  Drew tells us that Emacs has recently mapped "C-x x",
>> "C-x p" and "C-x /".  I'm using Emacs 27.1, so all of those must have
>> been mapped for Emacs 28 (or perhaps the version after that).
>
> Is that a problem? When such package finds out about a change like this, 
> they can change the default binding, or they might keep it as it was.

I disagree.  You're asking the authors of third-party packages to
constantly respond to the capricious behaviour of the maintainers.  I
think they're likely to take their efforts elsewhere if that continues.

I think Third party package authors should not have to do that.  The
maintainers of Emacs should provide a way to deal with the situation.

> After all, the changes like the ones you have mentioned are additive, 
> both the project keymap and the later addition of buffer-related 
> commands on 'C-x x'. They haven't been there before, and a fair number 
> of users might not miss them if xyz-mode (which they do use) takes up 
> either of the sequences.

Don't you think that's a suboptimal situation?  Yes, it may be that some
users never miss features.  Perhaps lots of users never use your project
features because they have already bound C-x p to something else.

Equally well though, users may miss out on something that they would
have found useful.

I think it's better to do something about future collision up-front, to
deal with them *before* more happen.

>> The author of a third party package can't easily deal with that.  What if
>> their minor mode used "C-x x"?  In that case it will remove the keymaps
>> of a core feature (or the core feature will remove it's keymap).
>
> Minor mode keymaps generally override the global keymap.

But not usually in a way that causes conflicts.  Usually the keys that
minor modes over-ride are not used by other things.

In that past, when lots of development was in core Emacs managing key
collisions was an internal job amongst the maintainers.  Now there are
thousands of 3rd-party packages on ELPA and MELPA.

I don't think the hoping the muddling through will be OK is a good
policy.

>> As Gregory Heyting has pointed out, what about packages that are not
>> modes?  Not every package is a minor mode or major mode.  So, how should
>> other types of package behave?
>
> Depends on how their setup is documented. Minor or major modes are the 
> majority, though.
>
>> Lastly, the usability issue is still there.  I think beginners find this
>> kind of thing difficult.
>
> Having a key sequence overridden by a minor mode?
>
> Considering beginners don't usually read the manual, they might not even 
> know they are missing anything. Which might be a loss, of course, in 
> certain cases. But not a difficulty.

I don't see the distinction.  I think every loss is also a "difficulty".

>> These days there are lots of Emacs "starter
>> kits" that claim to make Emacs simpler.  A lot of what they do is
>> configuring third-party packages.
>> 
>> Philip Kaludercic suggested some code for prompting users before mapping
>> keys.  I think that's a good idea.
>
> Some infrastructure for suggesting custom key bindings might work, but I 
> feel the current third-party tradition has held up pretty well.

In my view what we've seen in this thread points the other way.  It
might have held up well in the past but it's showing it's age.

BR,
Robert Thorpe