all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jared Finder <jared@finder.org>
Cc: emacs-devel@gnu.org
Subject: Re: Additional cleanup around xterm-mouse
Date: Wed, 18 Nov 2020 19:40:42 +0200	[thread overview]
Message-ID: <83o8jupnqd.fsf@gnu.org> (raw)
In-Reply-To: <b7770504a9f6a17f87f2ec3c90bb9f3e@finder.org> (message from Jared Finder on Sun, 15 Nov 2020 22:29:20 -0800)

> Date: Sun, 15 Nov 2020 22:29:20 -0800
> From: Jared Finder <jared@finder.org>
> Cc: emacs-devel@gnu.org
> 
> >> The first patch is very straightforward and should be trivial to 
> >> review
> >> and merge.
> > 
> > Agreed.
> 
> Great. It's completely independent of the other change, feel free to 
> merge at any time.

Soon.

> > Can you think about a way of doing this that will affect only
> > xterm-mouse?  I'm okay with, for example, replacing read-event in
> > those cases with some new function that will call a special
> > xterm-mouse API when xterm-mouse is in effect, and will call
> > read-event otherwise.  Is something like this feasible?
> 
> I was a little nervous about changing read-key's default behavior too.  
> Happy to explore other options. :)
> 
> Creating such an alternative function doesn't appear too bad if you're 
> okay with having the same run-with-idle-timer pattern that read-key 
> uses.  I do not think it can be xterm specific as it needs to apply all 
> of input-decode-map to be able to return function keys such as [f1] on a 
> native Linux term or an xterm.  (This is important for 
> widget-key-sequence-read-event.)

I don't think I follow.  All the places where you need changes are
related to handling mouse events, so why cannot it be specific to
xt-mouse?

> However, it can avoid the rest of the complexity of
> read-key-sequence.  I'm imagining something like this (untested code
> follows, just wanted to give a flavor of it):
> 
> (defun read-decoded-key ()  ; I'd love a better name here.
>    ;; Start of code like read-key's code.
>    (let ((keys '())
>          (timer (run-with-idle-timer
>                  read-key-delay t
>                  (lambda ()
>                    (unless (null keys)
>                      (throw 'read-key nil))))))
>      (unwind-protect
>          (while t (push (read-event) keys))
>        (cancel-timer timer))
> 
>      ;; Start of new stuff: Apply transformations from input-decode-map.
>      (do-stuff)
> 
>      (vconcat (nreverse keys))))

Doesn't look too bad, but I don't think I have a clear idea of how you
thought to use this in those places where you need xt-mouse to be
supported?

> An alternative is to just use read-key as is in most cases and make my 
> change a parameter / special variable.  Most of my patch's changes work 
> fine with the existing behavior of read-key.  Only the following changes 
> do not:
> 
> * lisp/vc/ediff-wind.el (ediff-get-window-by-clicking)
> ==> As coded, expects the first mouse event returned by read-event to be 
> a down-mouse-X event, which it then follows by another call to 
> read-event to get the mouse-X event.  It could be easily changed to only 
> look for the up event.
> 
> * lisp/strokes.el (strokes-read-stroke, strokes-read-complex-stroke)
> * lisp/textmodes/artist.el (artist-mode-draw-poly)
> ==> These both expect to detect a mix of down-mouse-X and mouse-X 
> events.
> 
> * lisp/wid-edit.el (widget-key-sequence-read-event)
> ==> This w/o changes to read-key, but with a behavior change.  With no 
> changes to read-key it returns just a single up event.  Currently on 
> other environments you get both a down and up event (e.g. <down-mouse-1> 
> <mouse-1>).

I think I like this latter alternative better.  It is slightly less
elegant, but simpler and less risky.  Can you show a draft of a patch
along those lines?

Thanks.



  parent reply	other threads:[~2020-11-18 17:40 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 [this message]
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.
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=83o8jupnqd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jared@finder.org \
    /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.