Re: Additional cleanup around xterm-mouse

[Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>]

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