GNU bug report logs - #29104
[PATCH]: xterm-mouse-mode clicks in the modeline dont use the keymap properties of the modeline strings

Previous Next

Full log

Message #14 received at 29104 <at> debbugs.gnu.org (full text, mbox):

From: "olaf.rogalsky <at> t-online.de" <olaf.rogalsky <at> t-online.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "29104 <at> debbugs.gnu.org" <29104 <at> debbugs.gnu.org>
Subject: AW: bug#29104: [PATCH]: xterm-mouse-mode clicks in the modeline
 dont use the keymap properties of the modeline strings
Date: Mon, 13 Nov 2017 12:33:21 +0100 (CET)

> This is no longer about input-decode-map, it's about
> key-translation-map.  And xterm-mouse-mode doesn't use
> key-translation-map, so why change this part?

This hunk, and the hunk

@@ -9647,6 +9649,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize,
Lisp_Object prompt,
                /* Adjust the input-decode-map counters.  */
                indec.end += diff;
                indec.start += diff;
+                first_event = mock_input > 0 ? keybuf[0] : Qnil;

                goto replay_sequence;
              }

are actually unrelated to xterm-mouse and where included for symmetry,
only. But I still think, its correct to do so:

After initialization, the only place where first_event is set, is at
line 9282:

          if (NILP (first_event))
            {
              first_event = key;

Unfortunately, this line is not reached during the replay of a key
translation (either input-decode-map or key-translation-map). So after
a key translation, ideally one should check, if the first key of the
key sequence was translated, and set first_event accordingly. But
since keybuf[0] holds the first event in any case, I set first_event
unconditionally to keybuf[0].

The reason, why this bug has not been recognized so far is, that the
only use of first_event is as an argument to the function
active_maps. In that function, first_event is ignored, if it is not a
mouse event. Afaik,translations, which result in mouse events, are
only generated xterm-mouse.

Summarizing, I believe, it does no harm to also set first_event after a
key-translation-map, but I included these to hunks for consistency
only. I would understand you, if you fear, that we might not
fully understand its consequences.


> The next question is whether this patch caters correctly to features
> other than xterm-mouse-mode.  The input-decode-map is used by
> terminal-specific support in xterm.el and rxvt.el -- does it still
> make sense to use keybuf[0] as first_event for replaying their
> sequences?

Yes I think so. As mentioned before, the only use of first_event is,
in active_maps(first_event), which prepends the active maps with the
local-map property after a mouse click. If first_event is not a mouse
event, its particular value is ignored. xterm.el and rxvt.el do not
generate mouse events and are therefore not affected (but even if they
did, setting first_event to keybuf[0] would still be the right thing).

Just for reference, this is the definition of active_maps():

static Lisp_Object
active_maps (Lisp_Object first_event)
{
  Lisp_Object position
    = CONSP (first_event) ? CAR_SAFE (XCDR (first_event)) : Qnil;
      |                     |                               |
      check for compound    get mouse position              otherwise ignore
      event (mouse click)                                   first_event

  return Fcons (Qkeymap, Fcurrent_active_maps (Qt, position));
}

Olaf


----------------------------------------------------------------
Gesendet mit Telekom Mail <https://t-online.de/email-kostenlos> - kostenlos und sicher für alle!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.