emacs-devel
[Top][All Lists]
Advanced

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

Re: Additional cleanup around xterm-mouse


From: Jared Finder
Subject: Re: Additional cleanup around xterm-mouse
Date: Sat, 19 Dec 2020 23:26:20 -0800
User-agent: Roundcube Webmail/1.3.15

On 2020-12-19 2:50 pm, Stefan Monnier wrote:
Let's see what Stefan suggests here.  Stefan?

I'm afraid I don't have much time to think about this.

My suggestion is to add an option to `read-key` which makes it ignore
`function-key-map` and all other hardcoded remappings that are only
applied when a key sequence is not bound (i.e. those remappings which
could/should conceptually be applied by `function-key-map` but aren't
for various historical/technical reasons, such as dropping `down` events,
demoting `drag` events, downcasing letters, ...).

At the level of `read-key-sequence` this should use the
`dont-downcase-last` argument (since `read-key` only reads one event,
it's OK if `read-key-sequence` only applies it to the last event).

This sounds straightforward to me to implement. The only question I have is how to handle backward compatibility.

I see a few options:

1. Change the behavior of the dont-downcase-last parameter to this more extensive meaning. Update global-set-key (the only other caller who sets dont-downcase-last in Emacs' code) to take this new behavior into account.

2. Make the dont-downcase-last parameter have the new behavior only if it is passed some new value (for example: 'all-fallbacks). Leave the existing behavior for any other value, especially 'nil and 't.

3. [My preference] Like 2, but with a deprecation message on values other than 'nil, 'all-fallbacks, or 't (or maybe 'downcase-last if we want full explicitness). This allows maximal ability to define new behaviors in the future.


I like #3 as existing code would run unchanged. The chance that any existing code passed 'all-fallbacks is extremely low. And anyone supporting a package outside of Emacs passing some other value will notice the message when they upgrade to Emacs 28.

Thoughts?

  -- MJF



reply via email to

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