Re: Additional cleanup around xterm-mouse

[Eli Zaretskii]

> Date: Wed, 23 Dec 2020 09:21:10 -0800
> From: Jared Finder <jared@finder.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> +(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.

And xterm-mouse-mode does need these down-mouse events?  For what
purpose?

> 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.

I prefer 3 or 2.  1 sounds too radical to me.  It's true that in core
there's only one caller, but we have no idea what happens outside of
the core.