emacs-devel
[Top][All Lists]
Advanced

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

Re: master 3b41141708: Expose the name of an event's input device to Lis


From: Stefan Monnier
Subject: Re: master 3b41141708: Expose the name of an event's input device to Lisp
Date: Sat, 09 Apr 2022 12:33:00 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> If the events are to be interpreted as usual in some situations and
> differently in others, we could have a special mode or variable to
> change the produced events only when we want that to be.

I'd prefer we don't do that.  This is the kind of thing we do for
`keyboard-coding-system` (the (sequence of) events we generate depends
on that variable) and it causes real problems for all those places in
the code that want to peek at the next event without consuming it
(starting with `sit-for`).

> Alternatively, we could always produce special kinds of events, and
> have them mapped to the same commands as the "normal" events.  For
> example, touchpad-button-1 could be mapped to the same command as
> mouse-1 in most cases, but when we want to treat those touchpad events
> specially, we could rebind them to other commands.

This behaves better, indeed.

The downside is that we currently don't have a good way to define
remapping like `touchpad-button-1` to `mouse-1` (the mechanism we have
works for that exact event but you then need to add N other mappings for
the cases where it's combined with control, meta, meta+control,
hyper+control, shift+control+double, ...).

>> The individual command will have to know about the device to treat it
>> correctly, just as elsewhere: web browsers, programs using GTK, Qt, etc.

Elsewhere tells us that the behavior depends on the device, but not that
the choice is made within their equivalent of "individual commands" nor
that this place would be the better choice.

I don't know where's the better place in general but if it can be made
via keymaps it might be preferable since we usually don't like commands
to behave differently for different events, we prefer instead to have
the keymaps decide which command to use for which event and then have
the command be oblivious to the event.

[ There are some notable exceptions to this general design, admittedly.
  E.g. `self-insert-command` looks at the event to know which char to
  insert, or the commands which obey `use-dialog-box` of those that
  obey `shift-select-mode`.  ]

> Does this really sound clean and maintainable?  Am I really the only
> one who's worried by that kind of design?  Stefan, Lars, Richard?

I agree that we'll usually want to hide those issues from commands.
I don't think the current code which exposes the device name to ELisp is
wrong, OTOH (after all, I like to keep the C code to a minimum).
But it's just not sufficient in the sense that we want to add to it some
abstraction layer so individual commands don't need to know about the
various possible input devices.


        Stefan




reply via email to

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