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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Sun, 10 Apr 2022 14:23:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why "different indexes to get the same property"?  The additional
> > members should provide additional information, unavailable in the
> > original elements.  We already have such data structures in Emacs;
> > see, for example, data structures returned by pos-visible-in-window-p
> > and find-composition.  The list returned by posn-at-point is another
> > example: the 2nd member can be either display area or buffer position,
> > and the 6th member always reports the position.  So this is quite
> > "normal" in Emacs, assuming that the data structure is designed to be
> > convenient for the code that will use it.
> 
> Because it doesn't make sense for this additional information to obscure
> information that is already available.
> 
> For example, we might extend `wheel-up' and `wheel-down' with an extra
> DEVICE parameter, so that it might look something like this:
> 
>   (wheel-down POSITION CLICKS LINES PIXEL-DELTA DEVICE)
> 
> But for touch end events, it would look like this:
> 
>   (touch-end POSITION DEVICE)
> 
> And for pinch events,
> 
>   (pinch POSITION DX DY SCALE ANGLE DEVICE)
> 
> To access the device would require the 6th, 3rd and 7th elements of each
> type of event, which is very confusing.

We have this in many places in Emacs already, so adding one more will
not hurt too much.  Dispatch on the first element of the list is easy
and produces code that is quite readable and maintainable, IMO.

Of course, if more elegant ways exist, I don't object to using them,
quite the contrary.  But if not, I see nothing especially wrong with
doing what you call "very confusing", because we do it elsewhere.