all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Jared Finder via \"Emacs development discussions.\""
	<emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
Subject: Re: Additional cleanup around xterm-mouse
Date: Wed, 02 Dec 2020 21:46:53 -0800	[thread overview]
Message-ID: <b534b51174b099ec7f976279199f0cab@finder.org> (raw)
In-Reply-To: <jwvblfcnogs.fsf-monnier+emacs@gnu.org>

On 2020-12-02 8:53 am, Stefan Monnier wrote:
>> Subject: [PATCH] Make libraries work with xterm-mouse-mode.
> 
> Could you explain (at least in the code, and ideally here as well) why
> we need this new `all-mouse-events` behavior?

I updated the function locally to look like as follows.  Let me know if 
you have further questions.

(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."
     ;; `xterm-mouse-mode' events must go through `read-key' as they
     ;; are decoded via `input-decode-map'.
     (if xterm-mouse-mode
         (read-key nil
                   ;; Normally `read-key' discards all mouse button
                   ;; down events.  However, we want them here.
                   t)
       (read-event)))

> `function-key-map` has very similar effects (and to a large extent, the
> downgrading of mouse-down events controlled by `all-mouse-events` could
> (I'd even say should) be implemented in `function-key-map` rather than
> via the current ad-hoc code in read-key-sequence), so I'm not very
> comfortable with treating these mouse-event-rewritings differently from
> other rewritings.

Just a few comments:

Wouldn't that require binding 2^6 * 3 * 3 * 5 = 2880 events in 
function-key-map? (2^6 for six modifier keys, 3 for down vs up vs drag, 
3 for single vs double vs triple, 5 for the mouse buttons).  Is that an 
okay overhead to add on every key press?  If not, it could instead be 
done with a default binding in function-key-map.

In both of the above cases, I believe the mapping would need to be a 
Lisp function so it can conditionally decay a triple down event to a 
double, single, or nothing depending on what is bound.

And such behavior would want a special variable (as the code is 
currently in my patch) to disable it to avoid copying all of 
function-key-map in read-key.  So I think it is fully independent of my 
current patch.

> The other question is why you made `all-mouse-events` an argument to
> `read-key` but not to `read-key-sequence` (where you pass the info via
> a dynamically-scoped var instead)?

I did this to create an API for read-key but not for read-key-sequence.  
Any package that wants to read down mouse events and work with 
xterm-mouse should call (read-key nil t).  I didn't want to create a way 
to do the same think for read-key-sequence at I could not think of a use 
case.  The special variable is named inhibit--unbound-mouse-fallback to 
indicate it is private and could change or be removed in the future.

   -- MJF



  reply	other threads:[~2020-12-03  5:46 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16  6:29 Additional cleanup around xterm-mouse Jared Finder via Emacs development discussions.
2020-11-16 17:30 ` Jared Finder via Emacs development discussions.
2020-11-18 17:40 ` Eli Zaretskii
2020-11-19  8:03   ` Jared Finder via Emacs development discussions.
2020-11-21  9:31     ` Eli Zaretskii
2020-11-22 23:56       ` Jared Finder via Emacs development discussions.
2020-11-28 16:36         ` Eli Zaretskii
2020-12-01  7:36           ` Jared Finder via Emacs development discussions.
2020-12-01 15:21             ` Stefan Monnier
2020-12-01 18:23             ` Eli Zaretskii
2020-12-02  6:45               ` Jared Finder via Emacs development discussions.
2020-12-02 16:53                 ` Stefan Monnier
2020-12-03  5:46                   ` Jared Finder via Emacs development discussions. [this message]
2020-12-03 14:45                     ` Stefan Monnier
2020-12-03 17:31                       ` Jared Finder via Emacs development discussions.
2020-12-14  0:54                         ` Jared Finder via Emacs development discussions.
2020-12-14 15:32                           ` Eli Zaretskii
2020-12-16  5:30                             ` Jared Finder via Emacs development discussions.
2020-12-19 18:32                               ` Eli Zaretskii
2020-12-19 22:50                                 ` Stefan Monnier
2020-12-20  7:26                                   ` Jared Finder via Emacs development discussions.
2020-12-20 14:07                                     ` Stefan Monnier
2020-12-20 23:27                                       ` Jared Finder via Emacs development discussions.
2020-12-23 16:52                                         ` Eli Zaretskii
2020-12-23 17:21                                           ` Jared Finder via Emacs development discussions.
2020-12-24 18:43                                             ` Eli Zaretskii
2020-12-14  0:36               ` Jared Finder via Emacs development discussions.
2020-11-21 17:00     ` Stefan Monnier
2020-11-21  8:23   ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2020-12-26 23:49 Jared Finder via Emacs development discussions.
2020-12-27 15:36 ` Stefan Monnier
2020-12-27 16:30   ` Jared Finder via Emacs development discussions.
2020-12-27 17:10     ` Stefan Monnier
2020-12-28  0:22       ` Jared Finder via Emacs development discussions.
2021-01-02  8:17 ` Eli Zaretskii
2021-01-02 22:20   ` Jared Finder via Emacs development discussions.
2021-01-09 12:27     ` Eli Zaretskii
2021-01-09 23:01       ` Jared Finder via Emacs development discussions.
2021-01-15 11:54         ` Eli Zaretskii
2020-11-15  8:49 Jared Finder via Emacs development discussions.
2020-11-15 18:11 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b534b51174b099ec7f976279199f0cab@finder.org \
    --to=emacs-devel@gnu.org \
    --cc=eliz@gnu.org \
    --cc=jared@finder.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.