Re: Additional cleanup around xterm-mouse

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

On 2020-12-23 8:52 am, Eli Zaretskii wrote:
>> Date: Sun, 20 Dec 2020 15:27:10 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> 
>> >> 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?
>> >
>> > By order of preference, I'd say: #1, then #3 and finally #2.
>> > But any one of those 3 is OK for me.
>> 
>> Sounds good to me! Eli, do you have a preference here? I'd like to 
>> make
>> sure I implement the right option.
> 
> I'm afraid I've lost context here.  Your suggestion was to use this:
> 
>> +(defun read-potential-mouse-event ()
>> +    "Read an event that might be a mouse event.
>> +
>> +This function exists for backward compatibility in code packaged
>> +with Emacs.  Do not call it directly in your own packages."
>> +    (if xterm-mouse-mode
>> +        (read-key nil t)
>> +      (read-event)))
> 
> This uses read-key when xterm-mouse-mode is in use, otherwise uses
> read-event as we did before.
> 
> But now the discussion is about read-key only, and also about
> read-key-sequence, which was not on the table at all, AFAIR?  There
> seems to be some gap here that I couldn't bridge upon.

The additional thing to keep in mind is that read-key is implemented on 
top of read-key-sequence.  read-key currently will never return down 
mouse events due to them being discarded in the (C function) 
read_key_sequence.

I highlighted a way to do this in the original patch in this email 
thread.  Stefan requested an alternative, which is to extend the 
behavior of the dont-downcase-last parameter to read-key-sequence. As 
this changes behavior for read-key-sequence, I want to know what is the 
right way to make this behavior change.

To simplify things, I think we can only look at #1 and #3, as both 
Stefan and I agree #3 is better than #2. The three choices I presented 
were:

1. [Stefan's preference] 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.

> So I'm sorry for slowing you down, but could you explain how the 3
> possibilities you describe are related to the original issue, which
> was that read-event is insufficient to support xterm-mouse-mode in
> those places?

No need to apologize. I realize read_key_sequnce is the *CORE* part of 
Emacs' input handling so any change needs to be handled with utmost 
care.

   -- MJF