[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: |
Eli Zaretskii |
Subject: |
Re: master 3b41141708: Expose the name of an event's input device to Lisp |
Date: |
Sat, 09 Apr 2022 12:30:33 +0300 |
> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Sat, 09 Apr 2022 17:06:35 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > And you never explained in enough detail why we would need to know
> > about "devices" when we use other event types. You said something
> > about keyboards, but I still don't understand why we would care about
> > the type of a keyboard.
> >
> > What other kinds of input could need this information, and why?
>
> Well as another example, artist-mode might want to behave differently
> with an "eraser" pointer, removing pixels from the picture instead of
> adding them.
Why cannot this be handled by producing special events that erase
pixels?
> Different keyboard might have different layouts (and input
> methods want to behave differently)
I don't think I understand why, see below.
> or lilypond-mode might want to insert notes directly from a MIDI
> keyboard while allowing typing from a normal keyboard.
Again, why not implement this as special events?
> > That was not yet demonstrated. Though every system has some notion of
> > "input device", the information they expose could be utterly different
> > and not necessarily appropriate for us. Your additions express
> > devices as strings, and strings don't necessarily carry any useful
> > information to explain the significance. And I don't think you have
> > explained anywhere what aspects of the "devices" we'd want to know
> > about, and why.
>
> We want to know whether a device is a mouse, trackpoint, eraser, pen,
> puck, device control, keyboard, touchscreen, touchpad or MIDI keyboard,
> and whether or not it's a different device from some other device, and
> also tell apart a single device from anotherq whenever possible.
I still don't understand why special-purpose events cannot solve the
same problems. Maybe even specialized mode with the same events.
> What would you think about allowing the device structure to be something
> other than a string (i.e. window-system dependent, like the argument to
> drag-n-drop events), that should be treated as opaque except when passed
> to functions like `device-class', and probably `device-equal'?
If we must. But I'm not yet convinced we must have this information.
> > And I suggested an alternative for dealing with these differences: new
> > kinds of input events. AFAIU, going that way will completely avoid
> > introducing the notion of a "device" into input events.
>
> That won't be very flexible, and it'll be very difficult for the user to
> write customizations for some new kind of device (or just a different
> device) without adding an entirely new kind of input event for it.
Please explain these two counter-arguments in more detail. Why "not
very flexible" and why it will make customizations more difficult?
> > We do? why? I think we definitely DON'T. Emacs is not a GUI toolkit,
> > it is a client of such toolkits. We use toolkits because we do NOT
> > want to deal with device-dependent behavior, we want to use
> > device-independent abstractions. If some device is unable to do
> > something, it will not produce events that express that functionality,
> > and the corresponding Emacs commands will not be invoked. That is all
> > I think Emacs needs to support each input device as appropriate.
>
> To most programs, the graphics tablet buttons are just mouse buttons.
> In Emacs, they will just send mouse-1 through 8 when clicked.
And why is that a problem? We already interpret mouse-4 and mouse-5
as the wheel, so why not have mouse-8 be interpreted in some special
way?
> And what if the user has two ordinary mice connected, and wants one to
> behave differently from the other, in effect giving him an extra set of
> mouse buttons?
What about it? Why does this require to know about the device, and
cannot be expressed as special events?
> > I don't think I understand. What would you like Emacs to support in
> > conjunction with Xkb, and what will Emacs have to learn about that for
> > it to "understand" those "configurations" (and what are those
> > "configurations", btw, i.e. what discerns one "configuration" from
> > another?).
>
> The simple use case of having two different keyboards behave
> differently. In my own specific case, they are printed with different
> layouts (one is US International, the other is Russian), but X only
> allows one keyboard layout for both the keyboards to be active.
Please tell more: how do they behave differently? If you press a key
that is labeled with some character, doesn't Emacs receive a keyboard
input event with that character?
> So to me, it would be nice to have different input methods for each
> individual keyboard, in order to not have to manually switch input
> methods each time.
We could have a keyboard-layout switch event, which would change input
methods automatically. (On MS-Windows, we already have such an
event.) Once again, low-level code does know about these details, and
that is not a problem IMO; it is exposing that to Lisp as "device"
that I don't like.
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, (continued)
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/08
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Lars Ingebrigtsen, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp,
Eli Zaretskii <=
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Po Lu, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Stefan Monnier, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Lars Ingebrigtsen, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Brian Cully, 2022/04/09
- Re: master 3b41141708: Expose the name of an event's input device to Lisp, Eli Zaretskii, 2022/04/09