Re: Additional cleanup around xterm-mouse

[Eli Zaretskii]

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

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?

TIA