|
From: | Jared Finder |
Subject: | Re: Additional cleanup around xterm-mouse |
Date: | Wed, 23 Dec 2020 09:21:10 -0800 |
User-agent: | Roundcube Webmail/1.3.15 |
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 makesure 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
[Prev in Thread] | Current Thread | [Next in Thread] |