unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Jared Finder <jared@finder.org>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Additional cleanup around xterm-mouse
Date: Sun, 27 Dec 2020 10:36:34 -0500	[thread overview]
Message-ID: <jwv7dp3l2ra.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <f06e43436fefcad5fd9e7371b84cad98@finder.org> (Jared Finder's message of "Sat, 26 Dec 2020 15:49:19 -0800")

> -@defun read-key &optional prompt
> +@defun read-key &optional prompt all-fallbacks-disabled

FWIW, I would call it "fallbacks-disabled".

> -          (key (read-key-sequence "Set key globally: " nil t)))
> +          (key (read-key-sequence
> +                "Set key globally: " nil
> +                ;; FIXME: It'd be nicer if this was set to
> +                ;; 'all-fallbacks, however that would not apply the
> +                ;; transformations applied by local-function-key-map,
> +                ;; for example control modified function keys.
> +                ;; `widget-key-sequence-read-event' queries the user
> +                ;; which key they want in this case, perhaps do the
> +                ;; same here?
> +                'downcase-last)))

The name `all-fallbacks` makes it sound like it *enables* all fallbacks.
Similarly `downcase-last` makes it sound like we'll downcase the last event.

Not sure what would be best, but I'd suggest `dont-fallback` and `dont-downcase-last`.

> -                  (catch 'read-key (read-key-sequence-vector prompt nil t)))
> +                  (catch 'read-key
> +                    (read-key-sequence-vector prompt nil
> +                                              (if all-fallbacks-disabled
> +                                                  'all-fallbacks
> +                                                'downcase-last))))

BTW, just like above, it might be the case that many/most uses of
`read-key` would actually prefer `dont-fallback`, so I think a FIXME
should be added here saying we should review all uses of `read-key`
to see if they would benefit from the use of the new argument.

> @@ -3490,11 +3490,11 @@ 'key-sequence
>  (defun widget-key-sequence-read-event (ev)
>    (interactive (list
>  		(let ((inhibit-quit t) quit-flag)
> -		  (read-event "Insert KEY, EVENT, or CODE: "))))
> +		  (read-key "Insert KEY, EVENT, or CODE: " t))))
>    (let ((ev2 (and (memq 'down (event-modifiers ev))
> -		  (read-event)))
> -	(tr (and (keymapp function-key-map)
> -		 (lookup-key function-key-map (vector ev)))))
> +		  (read-key nil t)))
> +	(tr (and (keymapp local-function-key-map)
> +		 (lookup-key local-function-key-map (vector ev)))))
>      (when (and (integerp ev)
>  	       (or (and (<= ?0 ev) (< ev (+ ?0 (min 10 read-quoted-char-radix))))
>  		   (and (<= ?a (downcase ev))

AFAICT this function doesn't make it possible to read double or triple clicks.
Maybe it should be consolidated with `help--read-key-sequence`.

> +   * If a key sequence is unbound, we check Vfunction_key_map to see
> +   if some trailing subsequence might be the beginning of a function
> +   key's sequence.  If so, we try to read the whole function key, and
> +   substitute its symbolic name into the key sequence.

Nowadays this deserves some serious quotes around "function key" since
function keys are normally handled in `input-decode-map` instead.

> +   * If a `down-' mouse click event is unbound, it is discarded.
> +
> +   * If a `drag-' or `double-' event is unbound, it is turned into
> +   similar click events if that would make them bound.  We try to turn
> +   `triple-' events first into `double-' events, then into clicks.
> +
> +   * If a capital letter is unbound, it is turned into a lower case
> +   letter if that would make it bound.
> +
> +   If FALLBACKS_DISABLED is Qnil, all of the above fallbacks are
> +   applied.  If it is Qall_fallbacks, then none of the fallbacks are
> +   applied.  If it is Qdowncase_last, the capital letter fallback is
> +   not applied, but all other ones are applied.

Hmm... now that I think about it, I wonder if we need to make changes in
`read_key_sequence` at all, because we can instead arrange for all keys
to be bound:

    diff --git a/lisp/subr.el b/lisp/subr.el
    index 725722cbee..1ca1d51d44 100644
    --- a/lisp/subr.el
    +++ b/lisp/subr.el
    @@ -2453,10 +2453,11 @@ memory-limit
     ;;;; Input and display facilities.
     
     (defconst read-key-empty-map (make-sparse-keymap))
    -
    +(defconst read-key-full-map
    +  (let ((map (make-sparse-keymap))) (define-key map [t] 'dummy) map))
     (defvar read-key-delay 0.01) ;Fast enough for 100Hz repeat rate, hopefully.
     
    -(defun read-key (&optional prompt)
    +(defun read-key (&optional prompt dont-fallback)
       "Read a key from the keyboard.
     Contrary to `read-event' this will not return a raw event but instead will
     obey the input decoding and translations usually done by `read-key-sequence'.
    @@ -2468,7 +2469,8 @@ read-key
       ;; always inherits the input method, in practice read-key does not
       ;; inherit the input method (at least not if it's based on quail).
       (let ((overriding-terminal-local-map nil)
    -       (overriding-local-map read-key-empty-map)
    +       (overriding-local-map
    +        (if dont-fallback read-key-full-map read-key-empty-map))
             (echo-keystrokes 0)
            (old-global-map (current-global-map))
             (timer (run-with-idle-timer

WDYT?

> diff --git a/src/lread.c b/src/lread.c
> index 3ef874039a..74ed474944 100644
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -782,6 +782,12 @@ DEFUN ("read-char", Fread_char, Sread_char, 0, 3, 0,
>  
>  DEFUN ("read-event", Fread_event, Sread_event, 0, 3, 0,
>         doc: /* Read an event object from the input stream.
> +
> +If you want to read mouse events (for example, to discard an expected
> +button up event inside a button down command), call `read-key' which
> +can return events via `input-decode-map' such as all mouse events
> +generated by `xterm-mouse-mode'.
> +
>  If the optional argument PROMPT is non-nil, display that as a prompt.
>  If PROMPT is nil or the string \"\", the key sequence/events that led
>  to the current command is used as the prompt.

I like that.  I'd say "decode events via" instead of "return events
via", tho.  And I'd also mention function keys since the same applies if
you want to read `f7` in a tty.


        Stefan




  reply	other threads:[~2020-12-27 15:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-26 23:49 Additional cleanup around xterm-mouse Jared Finder via Emacs development discussions.
2020-12-27 15:36 ` Stefan Monnier [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2020-11-16  6:29 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.
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
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=jwv7dp3l2ra.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).