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

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

bug#29478: [SUSPECTED SPAM] Re: [Patch] bug#29478: 26.0.90; `C-h k' foll


From: Stefan Monnier
Subject: bug#29478: [SUSPECTED SPAM] Re: [Patch] bug#29478: 26.0.90; `C-h k' followed by mouse clicks no longer shows down event
Date: Sun, 07 Jan 2018 13:03:19 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> We don't show unbound sequences anywhere else, except if they are
> explicitly asked about.  Not sure why this case should be different.

Try C-h c C-H-mouse-1 and it will dutifully report that C-H-mouse-1
is undefined.  IOW, this is really not a new behavior in `C-h c`.

>> I think it's also useful to show to the user than there were two events.
> I don't think I agree.  Moreover, when dragging there are more than 2
> events, but we only show 2.

Indeed, there's a whole bunch of options in terms of how much detail we
may want to show.

>> > Also, if both events are bound, I think we should show the mouse-N
>> > event before the down-mouse-N event, because the former is much more
>> > important and normally is the one that's bound.
>> 
>> If the down event is unbound it's not shown (this is actually not
>> a feature I actively tried to obtained: it's just the result of
>> read-key-sequence dropping the down event if it's not bound).
> That's an inconsistency I don't think I like.

Neither do I.  But it would require a fairly nasty hack to try and make
it behave differently, and given all the key remapping we do, there will
always be such inconsistencies, I think.

OTOH, for text-terminals, we add a "(translated from <escape-sequence>)"
and we could do the same here (that's what my patch originally did, by
the way, and that's what I've been using all these years since I think
it's very valuable information), which would say:

   <C-H-mouse-1> (translated from <C-H-down-mouse-1> <C-H-mouse-1>)
   at that spot is undefined

thus exposing the fact that there was also a <C-H-down-mouse-1> event
that got dropped along the way.

>> And I think it's important to preserve the order of the events.
> The order reversed is still an order ;-)

I guess if we reverse them all (i.e. always show events last-to-first),
I could live with it.

>> As a side-benefit it reduces the amount of ad-hoc code that needs to
>> know about what is a down event or a mouse event and so on.
> Yes, correct solutions frequently need more messy code ;-)

In my experience it too often leads to code which is "more correct" in
90% of the cases but inconsistent in the rest.


        Stefan





reply via email to

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