bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29104: AW: bug#29104: [PATCH]: xterm-mouse-mode clicks in the modeli


From: address@hidden
Subject: bug#29104: 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!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]