bug#74423: Low level key events

[Stefan Monnier]

> It provides events for press/release of keys, independently of the normal
> keyboard events. These events are bound int the special-event-map. Some lisp
> is included to implement detection of multiple tapping on keys, and running
> commands or simulating modifiers.

I hadn't followed the discussion over at emacs-devel, but this is cool.
I used to have a local patch which generated extra events for all key
presses/releases.  I never wrote any useful Lisp-level code for it
(all I had were bindings to ignore those events so Emacs was still
usable 🙂), but I really think it would make for fun new hacks.

I haven't had time to look at your whole patch, but here are some comments.

> +  (let ((key (cl-third last-input-event)))

Please try and use `event-*` functions.  If none serve (as will often be
the case), define local "replacements" until they can be promoted to
`subr.el`.

> +         ((functionp func) (funcall func))
> +         ((eq 'hyper func)
> +          (message "H-...")
> +          (let ((r (read-event)))
> +            (setq unread-command-events
> +                  (list (event-apply-modifier
> +                         r 'hyper 24 "H-"))))))))))

Move that code to a function, so you can get rid of this `hyper`
special case.  BTW, any reason why you couldn't use
`event-apply-hyper-modifier`?

[ BTW, this becomes more ... interesting ... when you want to be able to
  cumulative that for several modifiers, in which case your `read-event`
  might return an event which is not the one to which you want to add
  `H-`.  ]

> +  switch (keysym)
> +    {
> +    case GDK_KEY_Shift_L: key = Qlshift; break;
> +    case GDK_KEY_Shift_R: key = Qrshift; break;
> +    case GDK_KEY_Control_L: key = Qlctrl; break;
> +    case GDK_KEY_Control_R: key = Qrctrl; break;
> +    case GDK_KEY_Alt_L: key = Qlalt; break;
> +    case GDK_KEY_Alt_R: key = Qralt; break;
> +    default:
> +      key = Qnil;
> +    }
> +
> +   switch (keysym)
> +    {
> +    case GDK_KEY_Shift_L:
> +    case GDK_KEY_Shift_R:
> +      modifier = Qshift;
> +      break;
> +    case GDK_KEY_Control_L:
> +    case GDK_KEY_Control_R:
> +      modifier = Vx_ctrl_keysym;
> +      if (NILP (modifier))
> +     modifier = Qctrl;
> +      break;
> +    case GDK_KEY_Alt_L:
> +    case GDK_KEY_Alt_R:
> +      modifier = Vx_meta_keysym;
> +      if (NILP (modifier))
> +     modifier = Qalt;
> +      break;
> +    case GDK_KEY_Meta_L:
> +    case GDK_KEY_Meta_R:
> +      modifier = Vx_meta_keysym;
> +      if (NILP (modifier))
> +     modifier = Qmeta;
> +      break;
> +    case GDK_KEY_Hyper_L:
> +    case GDK_KEY_Hyper_R:
> +      modifier = Vx_hyper_keysym;
> +      if (NILP (modifier))
> +     modifier = Qhyper;
> +      break;
> +    case GDK_KEY_Super_L:
> +    case GDK_KEY_Super_R:
> +      modifier = Vx_super_keysym;
> +      if (NILP (modifier))
> +     modifier = Qsuper;
> +      break;
> +    default:
> +      modifier = Qnil;
> +    }

I think the list of low-level keys handled here should not be hard-coded.
IOW, maybe `enable-low-level-keys` should not be a boolean but
a list/map/table indicating which keys to handle.

> +  if (!NILP (key))
> +    {
> +      EVENT_INIT (inev.ie);
> +      XSETFRAME (inev.ie.frame_or_window, f);
> +      inev.ie.kind = LOW_LEVEL_KEY_EVENT;
> +      inev.ie.timestamp = xkey.time;
> +      inev.ie.arg = list2 (is_press ? Qt : Qnil, key);
> +      kbd_buffer_store_buffered_event (&inev, &xg_pending_quit_event);
> +    }
> +
> +  if (!NILP (modifier))
> +    {
> +      EVENT_INIT (inev.ie);
> +      XSETFRAME (inev.ie.frame_or_window, f);
> +      inev.ie.kind = LOW_LEVEL_MODIFIER_KEY_EVENT;
> +      inev.ie.timestamp = xkey.time;
> +      inev.ie.arg = list2 (is_press ? Qt : Qnil, modifier);
> +      kbd_buffer_store_buffered_event (&inev, &xg_pending_quit_event);
> +    }
> +}

So, IIUC you might generate 2 low-level events for a single key press?
Why?

Other note: in the distant past (back around Emacs-21) I seem to
remember Gerd making changes to the event structure so as to avoid
allocating Lisp objects for this code.  I think it was related to
problems due to running this low-level event-handler code from within
a C signal handler, which is a practice was have since stopped, luckily,
but maybe there are still good reasons to try and avoid involving
allocating objects into the Lisp heap in this low-level code.


        Stefan