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: Eli Zaretskii
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 19:46:05 +0200

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  29478@debbugs.gnu.org,  npostavs@users.sourceforge.net
> Date: Sun, 07 Jan 2018 10:31:38 -0500
> 
> > In general, I see the idea is to show both down-mouse-N event and
> > mouse-N event, both with "C-h c" and "C-h k".  That could be okay, but
> > why show undefined sequences?  E.g, "C-h c S-mouse-1" shows this in
> > the echo area:
> >
> >   <S-down-mouse-1> at that spot runs the command mouse-appearance-menu
> >   <S-mouse-1> at that spot is undefined
> 
> I did not make a special effort to do that, but I also didn't feel like
> stripping them away because sometimes it's useful to know what is the
> event name.  E.g. you want to bind something to "shifted left mouse
> click" because you noticed it doesn't do anything, so you already know
> it's undefined, but you don't yet know how to spell it.

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

> 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.

> > 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.

> And I think it's important to preserve the order of the events.

The order reversed is still an order ;-)

> 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 ;-)





reply via email to

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