Re: Additional cleanup around xterm-mouse

[Jared Finder]

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