emacs-devel
[Top][All Lists]
Advanced

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

Re: Input for TTY menus


From: Eli Zaretskii
Subject: Re: Input for TTY menus
Date: Fri, 18 Oct 2013 17:11:56 +0300

> Date: Fri, 18 Oct 2013 09:49:22 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > With GPM mouse it works on modeline,  if the mouse is over the modeline,
> > there're tips showing on the echo area and mouse click do bring up the menu.
> > One problem I found so far:  say I stay at a fundamental mode buffer and I
> > click Fundamental on modeline => Edit => Goto => Goto-Line, then the
> > focus(point) is on the buffer not on the minibuffer that prompts for input.
> 
> What you describe is the effect of clicking C-mouse-3 in the text
> area, not a click on the modeline.  If I click on the modeline, I
> don't get the Edit menu.  (But this is on Windows, so it's possible
> that GPM does something differently.)
> 
> But if I click C-mouse-3 in the text area, then yes, I see what you
> describe.  This is a consequence of some "cleverness" in the Emacs
> input processing, I hope some input guru could help out here.  Please
> submit a bug report.

This seems to happen because Emacs sees both down-mouse-1 and mouse-1
events, and the latter causes us to switch out of the minibuffer
window.  Here's what "C-h l" shows:

  <down-mouse-1> <goto> <mouse-1> <down-mouse-1> <go-to-line> <mouse-1>

What I don't understand is why is the mouse-1 click visible after the
menu is popped down.  The menu code in term.c removes all the mouse
events in the event queue before returning the event to its caller,
and on top of that, menu-bar.el binds mouse-1 to tty-menu-ignore.  So
this mouse-1 event (a) should not be seen at all, and (b) if it _is_
seen, it should have been ignored.  And yet here it is.

Stefan, can you please help out here?  What am I missing?  Maybe the
mouse events are not the reason?



reply via email to

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