Input for TTY menus

Input for TTY menus

[Eli Zaretskii]

[-- Attachment #1: Type: text/plain, Size: 4354 bytes --]

I need help from experts here on Emacs input in general and Emacs TTY
input in particular.

I'm working on adding support for menus on text-mode frames.  The code
which displays drop-down and pop-up menus, displays help-echo for the
menu items (in the echo area), and returns the user selection is
written, debugged, and works fairly well; as a teaser, I attach below
a few snapshots from my development machine.

The problem is how to drive the movement between, and selection of,
the menu items with keyboard input (or with mouse a on TTYs that
support mouse).  What is needed, as a minimum, is to be able to read
simple cursor motion commands (up/down/left/right) and RET, and
convert them into appropriate movements/selection in the menu.  We
should support not only the C-f/C-b/C-n/C-p keys, but also the arrow
keys which typically produce more-or-less arbitrary escape sequences.

Which of the Emacs input routines should I use to get this to work?
There's a gazillion of read_SOMETHING functions in keyboard.c.  After
some reading of the code and the commentary, I decided that read_char
is the one I need, as it seems to be capable of both reading
single-character keys and mouse events.  Is there a better function?

Anyway, an attempt to use read_char didn't succeed: when that function
is called after dropping down the first menu, Emacs gets stuck inside
'select', which never returns, no matter how many keys I press.
(Well, it will probably return after 100000 sec., but I didn't wait.)
IOW, when called in this manner, read_char somehow doesn't sense that
keyboard input arrived.

Is this supposed to work?  (I'm developing this on Windows, so what I
see might be some Windows-specific issue; I could continue development
on Unix, if read_char is supposed to work in this situation on Posix
platforms.)

Note that read_char is called recursively here, because x-popup-menu
is itself called from read_char.  Is it possible that read_char does
not tolerate recursive calls?

If using read_char for this is not a good idea, then what else should
I use?

Just in case it matters, here's the interesting part of the backtrace
recorded when read_char was called from the menu code (some functions
below Fx_popup_menu are new functions I wrote, so you will be unable
to find them in the current trunk sources, but their names will
hopefully tell what they do):

  #7  0x01227dc0 in sys_select (nfds=1, rfds=0x82f018, wfds=0x0, efds=0x0,
      timeout=0x82eff0, ignored=0x0) at w32proc.c:2096
  #8  0x011c47cd in wait_reading_process_output (time_limit=0, nsecs=0,
      read_kbd=-1, do_display=true, wait_for_cell=55961626, wait_proc=0x0,
      just_wait_proc=0) at process.c:4552
  #9  0x010e9ef1 in kbd_buffer_get_event (kbp=0x82f0cc, used_mouse_menu=0x0,
      end_time=0x0) at keyboard.c:3879
  #10 0x010e6578 in read_event_from_main_queue (end_time=0x0,
      local_getcjmp=0x82f2c0, used_mouse_menu=0x0) at keyboard.c:2230
  #11 0x010e67af in read_decoded_event_from_main_queue (end_time=0x0,
      local_getcjmp=0x82f2c0, prev_event=55961626, used_mouse_menu=0x0)
      at keyboard.c:2294
  #12 0x010e7b62 in read_char (commandflag=-2, map=55961626,
      prev_event=55961626, used_mouse_menu=0x0, end_time=0x0) at keyboard.c:2881
  #13 0x010d06bd in read_menu_input (sf=0x356f4d0, x=0x82f434, y=0x82f430,
      first_time=0x82f3e3) at term.c:3168
  #14 0x010d0c76 in tty_menu_activate (menu=0x3a482a0, pane=0x82f7dc,
      selidx=0x82f7d8, x0=1, y0=1, txt=0x82f7c4,
      help_callback=0x10d1377 <tty_menu_help_callback>) at term.c:3353
  #15 0x010d1b7e in tty_menu_show (f=0x356f4d0, x=1, y=1, for_click=1,
      keymaps=1, title=19586025, error_name=0x82f8b8) at term.c:3751
  #16 0x01074fad in Fx_popup_menu (position=60067158, menu=58308814)
      at menu.c:1358
  #17 0x010f230c in read_char_x_menu_prompt (map=58308814, prev_event=60067158,
      used_mouse_menu=0x82fb6b) at keyboard.c:8381
  #18 0x010e7587 in read_char (commandflag=1, map=58308814,
      prev_event=60067158, used_mouse_menu=0x82fb6b, end_time=0x0)
      at keyboard.c:2754
  #19 0x010f3843 in read_key_sequence (keybuf=0x82fc60, bufsize=30,
      prompt=55961626, dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true) at keyboard.c:9069
  #20 0x010e498c in command_loop_1 () at keyboard.c:1436

And here are the teaser images:


[-- Attachment #2: TTY_menus_menubar1.png --]
[-- Type: image/png, Size: 23948 bytes --]

[-- Attachment #3: TTY_menus_menubar2.png --]
[-- Type: image/png, Size: 24000 bytes --]

[-- Attachment #4: TTY_menus_C-mode.png --]
[-- Type: image/png, Size: 44220 bytes --]

[-- Attachment #5: TTY_menus_modeline.png --]
[-- Type: image/png, Size: 19456 bytes --]

Re: Input for TTY menus

[Masatake YAMATO]

On Thu, 19 Sep 2013 16:38:55 +0300, Eli Zaretskii <eliz@gnu.org> wrote:
> I need help from experts here on Emacs input in general and Emacs TTY
> input in particular.
> 
> I'm working on adding support for menus on text-mode frames.  The code
> which displays drop-down and pop-up menus, displays help-echo for the
> menu items (in the echo area), and returns the user selection is
> written, debugged, and works fairly well; as a teaser, I attach below
> a few snapshots from my development machine.

GREAT!!!
(Sorry, I'm not an expert.)

Re: Input for TTY menus

[Stefan Monnier]

> convert them into appropriate movements/selection in the menu.  We
> should support not only the C-f/C-b/C-n/C-p keys, but also the arrow
> keys which typically produce more-or-less arbitrary escape sequences.

> Which of the Emacs input routines should I use to get this to work?
> There's a gazillion of read_SOMETHING functions in keyboard.c.  After
> some reading of the code and the commentary, I decided that read_char
> is the one I need, as it seems to be capable of both reading
> single-character keys and mouse events.  Is there a better function?

read_char won't handle the arrow keys.  To handle the arrow keys you
need to use read_key_sequence (probably after setting up some
overriding-terminal-local-map).

> Anyway, an attempt to use read_char didn't succeed: when that function
> is called after dropping down the first menu, Emacs gets stuck inside
> 'select', which never returns, no matter how many keys I press.
> (Well, it will probably return after 100000 sec., but I didn't wait.)
> IOW, when called in this manner, read_char somehow doesn't sense that
> keyboard input arrived.

That's odd.  But I can't think of any reason why this could
happen, sorry.

> Note that read_char is called recursively here, because x-popup-menu
> is itself called from read_char.  Is it possible that read_char does
> not tolerate recursive calls?

I don't think so: read_char_minibuf_menu_prompt also calls
read_char recursively.

> Just in case it matters, here's the interesting part of the backtrace
> recorded when read_char was called from the menu code (some functions

Looks reasonable, sorry.


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Sep 2013 10:33:10 -0400
> 
> > convert them into appropriate movements/selection in the menu.  We
> > should support not only the C-f/C-b/C-n/C-p keys, but also the arrow
> > keys which typically produce more-or-less arbitrary escape sequences.
> 
> > Which of the Emacs input routines should I use to get this to work?
> > There's a gazillion of read_SOMETHING functions in keyboard.c.  After
> > some reading of the code and the commentary, I decided that read_char
> > is the one I need, as it seems to be capable of both reading
> > single-character keys and mouse events.  Is there a better function?
> 
> read_char won't handle the arrow keys.  To handle the arrow keys you
> need to use read_key_sequence

Thanks.  This means I'll probably need to clone some small subset of
the code in command_loop_1 after it calls read_key_sequence, in order
to process the key sequence, right?

> (probably after setting up some overriding-terminal-local-map).

What would be the purpose of overriding-terminal-local-map in this
case?

> > Anyway, an attempt to use read_char didn't succeed: when that function
> > is called after dropping down the first menu, Emacs gets stuck inside
> > 'select', which never returns, no matter how many keys I press.
> > (Well, it will probably return after 100000 sec., but I didn't wait.)
> > IOW, when called in this manner, read_char somehow doesn't sense that
> > keyboard input arrived.
> 
> That's odd.  But I can't think of any reason why this could
> happen, sorry.

OK, I will keep digging.

Re: Input for TTY menus

[Stefan Monnier]

>> read_char won't handle the arrow keys.  To handle the arrow keys you
>> need to use read_key_sequence
> Thanks.  This means I'll probably need to clone some small subset of
> the code in command_loop_1 after it calls read_key_sequence, in order
> to process the key sequence, right?

I don't think there's much to do there, but clearly you'll want to do
something with the sequence, indeed.  Although you might like to simply
setup your keymaps in such a way that you can just use
read_key_sequence_cmd (which should usually be the same as (key-binding
<keys>), except when the keymaps are dynamic and might change between
the time they were read by read_key_sequence and the call to
key-binding) to know what operation to perform.

>> (probably after setting up some overriding-terminal-local-map).
> What would be the purpose of overriding-terminal-local-map in this
> case?

The key sequences read by read_key_sequence depend on the currently
active keymaps to decide when a key sequence is complete (i.e. when to
stop reading subsequent events).


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Sep 2013 15:21:17 -0400
> 
> >> read_char won't handle the arrow keys.  To handle the arrow keys you
> >> need to use read_key_sequence
> > Thanks.  This means I'll probably need to clone some small subset of
> > the code in command_loop_1 after it calls read_key_sequence, in order
> > to process the key sequence, right?
> 
> I don't think there's much to do there, but clearly you'll want to do
> something with the sequence, indeed.  Although you might like to simply
> setup your keymaps in such a way that you can just use
> read_key_sequence_cmd (which should usually be the same as (key-binding
> <keys>), except when the keymaps are dynamic and might change between
> the time they were read by read_key_sequence and the call to
> key-binding) to know what operation to perform.
> 
> >> (probably after setting up some overriding-terminal-local-map).
> > What would be the purpose of overriding-terminal-local-map in this
> > case?
> 
> The key sequences read by read_key_sequence depend on the currently
> active keymaps to decide when a key sequence is complete (i.e. when to
> stop reading subsequent events).

Is it OK to bind keys in overriding-terminal-local-map to symbols
whose function cell is void?  (The C code interprets these symbols
when they are delivered by read_key_sequence via
read_key_sequence_cmd.)  It seems to work, but I wonder if that is
just be sheer luck, and should be discouraged for some reason.

Re: Input for TTY menus

[Stefan Monnier]

> Is it OK to bind keys in overriding-terminal-local-map to symbols
> whose function cell is void?

Yes.


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Sep 2013 10:33:10 -0400
> 
> > Anyway, an attempt to use read_char didn't succeed: when that function
> > is called after dropping down the first menu, Emacs gets stuck inside
> > 'select', which never returns, no matter how many keys I press.
> > (Well, it will probably return after 100000 sec., but I didn't wait.)
> > IOW, when called in this manner, read_char somehow doesn't sense that
> > keyboard input arrived.
> 
> That's odd.  But I can't think of any reason why this could
> happen, sorry.

Blocked input, that's why.  (In fact, 'select' did return, but
wait_reading_process_output would loop forever, even though 'select'
indicated that input is available.)  This is because menu.c calls
'block_input' before invoking the terminal-specific menu display
function; for the TTY menus, it doesn't make sense to block input,
obviously, since we are going to read keyboard/mouse input through
normal Emacs input channels.

Re: Input for TTY menus

[Darren Hoo]

Eli Zaretskii <eliz@gnu.org> writes:


> Is this supposed to work?  (I'm developing this on Windows, so what I
> see might be some Windows-specific issue; I could continue development
> on Unix, if read_char is supposed to work in this situation on Posix
> platforms.)
>

Is your work on Unix finished or still in progress? 
I've tried latest bzr revno: 114690 and it does not work on these
environments that I have used to test:

1. xterm on GNU/Linux, 
2. GPM-enabled virtual console on GNU/Linux.
3. iterm2 on OSX

while vim works (with :set mouse=a) in all these terminals.

Re: Input for TTY menus

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Thu, 17 Oct 2013 13:34:52 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
> > Is this supposed to work?  (I'm developing this on Windows, so what I
> > see might be some Windows-specific issue; I could continue development
> > on Unix, if read_char is supposed to work in this situation on Posix
> > platforms.)

That mail is ancient history.  I followed up in
http://lists.gnu.org/archive/html/emacs-devel/2013-09/msg00417.html
with explanation why I had those problems.

> Is your work on Unix finished or still in progress? 

Finished, see

  http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00258.html.

> I've tried latest bzr revno: 114690 and it does not work on these
> environments that I have used to test:
> 
> 1. xterm on GNU/Linux, 
> 2. GPM-enabled virtual console on GNU/Linux.
> 3. iterm2 on OSX

What do you mean by "does not work"?  Are the problems with the mouse,
or can't you even open the menus with F10 and then navigate with arrow
keys or with C-f/C-b/C-n/C-p?  The latter certainly works for me on
GNU/Linux.

If the problem is with the mouse, then xt-mouse indeed does not work
(it starts tmm-menubar instead).  I could not test with GPM, and I
don't know what is iterm2.  I don't have access to these environments,
so the text-mode mouse is only tested on Windows text terminal.
Details of why things don't work and patches are welcome.

Re: Input for TTY menus

[Darren Hoo]

Hi  Eli,

On Thu, Oct 17, 2013 at 11:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Finished, see
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00258.html.

I am sorry to have missed this one.
Excuse me for describing my problem earlier as vaguely as "does not work".
The problem is I actually didn't know how to use it. That post really
clear things
up for me.

>> I've tried latest bzr revno: 114690 and it does not work on these
>> environments that I have used to test:
>>
>> 1. xterm on GNU/Linux,
>> 2. GPM-enabled virtual console on GNU/Linux.
>> 3. iterm2 on OSX
>
> What do you mean by "does not work"?  Are the problems with the mouse,
> or can't you even open the menus with F10 and then navigate with arrow
> keys or with C-f/C-b/C-n/C-p?  The latter certainly works for me on
> GNU/Linux.

Great! the latter works for me too on either of the three above I tested.

There's one problem with the NS-build, the menu of text-mode of NS-Build
is like this:

     File Edit Options Tools Lisp-Interaction Buffers Services Help

        ^^^^^^^^^
The Services menu is empty(I think it is not of much use on text-mode)
So while cycling through the menu with right char (tty-menu-next-menu)
tty menu exits when it reaches Services thus  Help can not be reached
except using left char to go backwards.

> If the problem is with the mouse, then xt-mouse indeed does not work
> (it starts tmm-menubar instead).  I could not test with GPM, and I
> don't know what is iterm2.  I don't have access to these environments,
> so the text-mode mouse is only tested on Windows text terminal.
> Details of why things don't work and patches are welcome.

I see.

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.

Also with GPM, click on the top menu  it gives:
      <nil> <mouse-1> is undefined

It would be great that the top menu can be brought up by clicking as the
modeline does.

Re: Input for TTY menus

[Eli Zaretskii]

> Date: Fri, 18 Oct 2013 12:55:59 +0800
> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > What do you mean by "does not work"?  Are the problems with the mouse,
> > or can't you even open the menus with F10 and then navigate with arrow
> > keys or with C-f/C-b/C-n/C-p?  The latter certainly works for me on
> > GNU/Linux.
> 
> Great! the latter works for me too on either of the three above I tested.

Good news, thanks for testing.

> There's one problem with the NS-build, the menu of text-mode of NS-Build
> is like this:
> 
>      File Edit Options Tools Lisp-Interaction Buffers Services Help
> 
>         ^^^^^^^^^
> The Services menu is empty(I think it is not of much use on text-mode)
> So while cycling through the menu with right char (tty-menu-next-menu)
> tty menu exits when it reaches Services thus  Help can not be reached
> except using left char to go backwards.

Where does the "Services" item come from on NS?  It's not present on
other systems, AFAICS.

Also, if you invoke tmm-menubar with M-`, does the Services item
appear there, and if so, can it be selected and used as you'd expect?

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

> Also with GPM, click on the top menu  it gives:
>       <nil> <mouse-1> is undefined

That's strange, maybe there's some bug in keyboard.c.  Could you
please step with a debugger into the code in keyboard.c that starts
like this:

	/* A mouse click.  Figure out where it is, decide whether it's
	   a press, click or drag, and build the appropriate structure.  */
      case MOUSE_CLICK_EVENT:
  #ifndef USE_TOOLKIT_SCROLL_BARS
      case SCROLL_BAR_CLICK_EVENT:
  #endif
	{
	  int button = event->code;
	  bool is_double;
	  Lisp_Object position;
	  Lisp_Object *start_pos_ptr;
	  Lisp_Object start_pos;

	  position = Qnil;

	  /* Build the position as appropriate for this mouse click.  */
	  if (event->kind == MOUSE_CLICK_EVENT)
	    {
	      struct frame *f = XFRAME (event->frame_or_window);
	      int row, column;

and see what is going on there when GPM mouse is clicked on the menu
bar?  The expected result is that Emacs loops through menu items below
this code, finds the menu-bar menu item where you clicked, and return
a menu-bar click event like this:

		    position = list4 (event->frame_or_window,
				      Qmenu_bar,
				      Fcons (event->x, event->y),
				      make_number (event->timestamp));

		    return list2 (item, position);

Re: Input for TTY menus

[Darren Hoo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Also with GPM, click on the top menu  it gives:
>>       <nil> <mouse-1> is undefined
>
> That's strange, maybe there's some bug in keyboard.c.  Could you
> please step with a debugger into the code in keyboard.c that starts
> like this:
>
> 	/* A mouse click.  Figure out where it is, decide whether it's
> 	   a press, click or drag, and build the appropriate structure.  */
>       case MOUSE_CLICK_EVENT:
>   #ifndef USE_TOOLKIT_SCROLL_BARS
>       case SCROLL_BAR_CLICK_EVENT:
>   #endif
> 	{
> 	  int button = event->code;
> 	  bool is_double;
> 	  Lisp_Object position;
> 	  Lisp_Object *start_pos_ptr;
> 	  Lisp_Object start_pos;
>
> 	  position = Qnil;
>
> 	  /* Build the position as appropriate for this mouse click.  */
> 	  if (event->kind == MOUSE_CLICK_EVENT)
> 	    {
> 	      struct frame *f = XFRAME (event->frame_or_window);
> 	      int row, column;
>
> and see what is going on there when GPM mouse is clicked on the menu
> bar?  The expected result is that Emacs loops through menu items below
> this code, finds the menu-bar menu item where you clicked, and return
> a menu-bar click event like this:
>
> 		    position = list4 (event->frame_or_window,
> 				      Qmenu_bar,
> 				      Fcons (event->x, event->y),
> 				      make_number (event->timestamp));
>
> 		    return list2 (item, position);

I am not quite handy on this code, but I'll give it a try, is what follows
helpul?

Breakpoint 1, make_lispy_event (event=event@entry=0x841ddf0) at keyboard.c:5425
5425	{
(gdb) 
(gdb) list
5420	   are received; this function stores the location of button presses
5421	   in order to build drag events when the button is released.  */
5422	
5423	static Lisp_Object
5424	make_lispy_event (struct input_event *event)
5425	{
5426	  int i;
5427	
5428	  switch (event->kind)
5429	    {
(gdb) p event->kind
$3 = GPM_CLICK_EVENT
(gdb) n
5428	  switch (event->kind)
(gdb) 
5425	{
(gdb) 
5428	  switch (event->kind)
(gdb) 
6037		if (button >= ASIZE (button_down_location))
(gdb) 
6031		struct frame *f = XFRAME (event->frame_or_window);
(gdb) 
6035		int button = event->code;
(gdb) 
6037		if (button >= ASIZE (button_down_location))
(gdb) 
6031		struct frame *f = XFRAME (event->frame_or_window);
(gdb) 
6037		if (button >= ASIZE (button_down_location))
(gdb) 
6046		start_pos = *start_pos_ptr;
(gdb) 
6048		position = make_lispy_position (f, event->x, event->y,
(gdb) 
6046		start_pos = *start_pos_ptr;
(gdb) 
6048		position = make_lispy_position (f, event->x, event->y,
(gdb) 
6051	 	if (event->modifiers & down_modifier)
(gdb) 
6048		position = make_lispy_position (f, event->x, event->y,
(gdb) 
6051	 	if (event->modifiers & down_modifier)
(gdb) 
6052		  *start_pos_ptr = Fcopy_alist (position);
(gdb) 
6060		head = modify_event_symbol (button,
(gdb) 
6067		if (event->modifiers & drag_modifier)
(gdb) 
6069		else if (event->modifiers & double_modifier)
(gdb) 
6071		else if (event->modifiers & triple_modifier)
(gdb) 
6074		  return list2 (head, position);
(gdb) p head
$4 = 140490514
(gdb) p position
$5 = 142829718
(gdb) n

Re: Input for TTY menus

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Fri, 18 Oct 2013 15:37:06 +0800
> 
> I am not quite handy on this code, but I'll give it a try, is what follows
> helpul?

Yes, it's very helpful: I failed to notice that GPM mouse clicks are
reported as a different event kind, and are handled by separate code
(boy, do I hate this kind of segregation by platform-specific
conditions!).

Can you try the patch below, and see if it fixes the menu-bar issue
with GPM, and does not cause any adverse effects on the rest of GPM
mouse functionality?

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2013-10-18 04:27:34 +0000
+++ src/keyboard.c	2013-10-18 09:05:24 +0000
@@ -5547,6 +5547,9 @@ make_lispy_event (struct input_event *ev
       /* A mouse click.  Figure out where it is, decide whether it's
          a press, click or drag, and build the appropriate structure.  */
     case MOUSE_CLICK_EVENT:
+#ifdef HAVE_GPM
+    case GPM_CLICK_EVENT:
+#endif
 #ifndef USE_TOOLKIT_SCROLL_BARS
     case SCROLL_BAR_CLICK_EVENT:
 #endif
@@ -5560,7 +5563,11 @@ make_lispy_event (struct input_event *ev
 	position = Qnil;
 
 	/* Build the position as appropriate for this mouse click.  */
-	if (event->kind == MOUSE_CLICK_EVENT)
+	if (event->kind == MOUSE_CLICK_EVENT
+#ifdef HAVE_GPM
+	    || event->kind == GPM_CLICK_EVENT
+#endif
+	    )
 	  {
 	    struct frame *f = XFRAME (event->frame_or_window);
 	    int row, column;
@@ -6025,55 +6032,6 @@ make_lispy_event (struct input_event *ev
     case CONFIG_CHANGED_EVENT:
 	return list3 (Qconfig_changed_event,
 		      event->arg, event->frame_or_window);
-#ifdef HAVE_GPM
-    case GPM_CLICK_EVENT:
-      {
-	struct frame *f = XFRAME (event->frame_or_window);
-	Lisp_Object head, position;
-	Lisp_Object *start_pos_ptr;
-	Lisp_Object start_pos;
-	int button = event->code;
-
-	if (button >= ASIZE (button_down_location))
-	  {
-	    ptrdiff_t incr = button - ASIZE (button_down_location) + 1;
-	    button_down_location = larger_vector (button_down_location,
-						  incr, -1);
-	    mouse_syms = larger_vector (mouse_syms, incr, -1);
-	  }
-
-	start_pos_ptr = aref_addr (button_down_location, button);
-	start_pos = *start_pos_ptr;
-
-	position = make_lispy_position (f, event->x, event->y,
-					event->timestamp);
-
- 	if (event->modifiers & down_modifier)
-	  *start_pos_ptr = Fcopy_alist (position);
-	else if (event->modifiers & (up_modifier | drag_modifier))
-	  {
-	    if (!CONSP (start_pos))
-	      return Qnil;
-	    event->modifiers &= ~up_modifier;
-	  }
-
-	head = modify_event_symbol (button,
-				    event->modifiers,
-				    Qmouse_click, Vlispy_mouse_stem,
-				    NULL,
-				    &mouse_syms,
-				    ASIZE (mouse_syms));
-
-	if (event->modifiers & drag_modifier)
-	  return list3 (head, start_pos, position);
-	else if (event->modifiers & double_modifier)
-	  return list3 (head, position, make_number (2));
-	else if (event->modifiers & triple_modifier)
-	  return list3 (head, position, make_number (3));
- 	else
-	  return list2 (head, position);
-       }
-#endif /* HAVE_GPM */
 
       /* The 'kind' field of the event is something we don't recognize.  */
     default:

Re: Input for TTY menus

[Darren Hoo]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Fri, Oct 18, 2013 at 5:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>
> Can you try the patch below, and see if it fixes the menu-bar issue
> with GPM, and does not cause any adverse effects on the rest of GPM
> mouse functionality?

The patch works, neat really.

I think there's one more improvement  can be made.

for example click on the menu Options,  Click on the letter O or click on
letter i the position of the dropdown menu is different. please refer to the
screenshots attached,  I think the calculation of the position of the  the
drop down menu should always start from the first letter of the menu.

I wonder how it works on windows (having some trouble setting up the build
environment, are there any downloadable nightly builds?)  and whether the
behaviour cross platform is  consistent.

[-- Attachment #2: click_on_O.png --]
[-- Type: image/png, Size: 10107 bytes --]

[-- Attachment #3: click_on_i.png --]
[-- Type: image/png, Size: 9302 bytes --]

Re: Input for TTY menus

[Eli Zaretskii]

> Date: Fri, 18 Oct 2013 18:39:21 +0800
> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > Can you try the patch below, and see if it fixes the menu-bar issue
> > with GPM, and does not cause any adverse effects on the rest of GPM
> > mouse functionality?
> 
> The patch works, neat really.

Thanks for testing.  I committed the change.

> I think there's one more improvement  can be made.
> 
> for example click on the menu Options,  Click on the letter O or click on
> letter i the position of the dropdown menu is different. please refer to the
> screenshots attached,  I think the calculation of the position of the  the
> drop down menu should always start from the first letter of the menu.

That's how non-toolkit menus always worked: the menu is popped on the
same place where you click the mouse.  Personally, I rather like this,
but that's because I'm used to it.

If someone wants to work on changing that for clicks on the menu bar
(note that this should still work as it does for clicks on the text
area or elsewhere on the frame), I won't object, but I won't work on
this myself, sorry.

> I wonder how it works on windows

The same.  It also works the same on X when no toolkits are used, and
even on MS-DOS.

> (having some trouble setting up the build environment, are there any
> downloadable nightly builds?)

  https://sourceforge.net/projects/emacs-bin/files/snapshots/

> and whether the behaviour cross platform is consistent.

It is, as long as Emacs itself is creating the menus.  Toolkits don't
behave like that.

Re: Input for TTY menus

[Eli Zaretskii]

> Date: Fri, 18 Oct 2013 18:39:21 +0800
> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > Can you try the patch below, and see if it fixes the menu-bar issue
> > with GPM, and does not cause any adverse effects on the rest of GPM
> > mouse functionality?
> 
> The patch works, neat really.

Thanks for testing.  I committed the change.

> I think there's one more improvement  can be made.
> 
> for example click on the menu Options,  Click on the letter O or click on
> letter i the position of the dropdown menu is different. please refer to the
> screenshots attached,  I think the calculation of the position of the  the
> drop down menu should always start from the first letter of the menu.

That's how non-toolkit menus always worked: the menu is popped on the
same place where you click the mouse.  Personally, I rather like this,
but that's because I'm used to it.

If someone wants to work on changing that for clicks on the menu bar
(note that this should still work as it does for clicks on the text
area or elsewhere on the frame), I won't object, but I won't work on
this myself, sorry.

> I wonder how it works on windows

The same.  It also works the same on X when no toolkits are used, and
even on MS-DOS.

> (having some trouble setting up the build environment, are there any
> downloadable nightly builds?)

  https://sourceforge.net/projects/emacs-bin/files/snapshots/

> and whether the behaviour cross platform is consistent.

It is, as long as Emacs itself is creating the menus.  Toolkits don't
behave like that.

What about my questions about the "Services" menu?  I don't think you
answered those.

Re: Input for TTY menus

[Darren Hoo]

On Fri, Oct 18, 2013 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I think there's one more improvement  can be made.
>>
>> for example click on the menu Options,  Click on the letter O or click on
>> letter i the position of the dropdown menu is different. please refer to the
>> screenshots attached,  I think the calculation of the position of the  the
>> drop down menu should always start from the first letter of the menu.
>
> That's how non-toolkit menus always worked: the menu is popped on the
> same place where you click the mouse.  Personally, I rather like this,
> but that's because I'm used to it.
>
> If someone wants to work on changing that for clicks on the menu bar
> (note that this should still work as it does for clicks on the text
> area or elsewhere on the frame), I won't object, but I won't work on
> this myself, sorry.

That's OK, It doesn't bother me much, I can live with that.

>> (having some trouble setting up the build environment, are there any
>> downloadable nightly builds?)
>
>   https://sourceforge.net/projects/emacs-bin/files/snapshots/

Great! saves me a lot of hassle.

>> and whether the behaviour cross platform is consistent.
>
> It is, as long as Emacs itself is creating the menus.  Toolkits don't
> behave like that.

I assume that's the power of abstraction, right? I do not know how Emacs
actually does the cross platform thing, But I think I will get to know it.

Re: Input for TTY menus

[Darren Hoo]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

On Fri, Oct 18, 2013 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> What about my questions about the "Services" menu?  I don't think you
> answered those.

Thanks chad for explaining what  services menu for me.

Jan,

your  114716 commit totally removes the services menu. But I think some GUI
users may use it, I sometimes use it while not quite often.

How about bring it back? I have tested the following patch on OSX,
While I tried Emacs on GNUStep it crashes , but I don't think the crash is
related to this.

I am curious that how many users use Emacs on GNUStep nowadays?

=== modified file 'lisp/menu-bar.el'

--- lisp/menu-bar.el 2013-10-19 08:35:51 +0000

+++ lisp/menu-bar.el 2013-10-19 18:14:38 +0000

@@ -45,16 +45,24 @@

     ;; The symbol used to be called `help', but that gets confused with the

     ;; help key.

     (setq menu-bar-final-items '(help-menu))

-  (if (eq system-type 'darwin)

-      (setq menu-bar-final-items '(buffer services help-menu))

-    (setq menu-bar-final-items '(buffer services hide-app quit))

-    ;; Add standard top-level items to GNUstep menu.

-    (bindings--define-key global-map [menu-bar quit]

-      '(menu-item "Quit" save-buffers-kill-emacs

-                   :help "Save unsaved buffers, then exit"))

-    (bindings--define-key global-map [menu-bar hide-app]

-      '(menu-item "Hide" ns-do-hide-emacs

-                  :help "Hide Emacs"))))

+  (if (eq window-system nil)

+      ;; No services menu in text-mode.

+      (if (eq system-type 'darwin)

+   (setq menu-bar-final-items '(buffer help-menu))

+ (setq menu-bar-final-items '(buffer hide-app quit)))

+    ;; We still want to use service menu in GUI.

+    (if (eq system-type 'darwin)

+ (setq menu-bar-final-items '(buffer services help-menu))

+      (setq menu-bar-final-items '(buffer services hide-app quit))

+      ;; Add standard top-level items to GNUstep menu.

+      (bindings--define-key global-map [menu-bar quit]

+ '(menu-item "Quit" save-buffers-kill-emacs

+     :help "Save unsaved buffers, then exit"))

+      (bindings--define-key global-map [menu-bar hide-app]

+ '(menu-item "Hide" ns-do-hide-emacs

+     :help "Hide Emacs")))

+    (bindings--define-key global-map [menu-bar services] ; Set-up in
ns-win.

+      (cons "Services" (make-sparse-keymap "Services")))))



 ;; This definition is just to show what this looks like.

 ;; It gets modified in place when menu-bar-update-buffers is called.

[-- Attachment #2: Type: text/html, Size: 5537 bytes --]

Re: Input for TTY menus

[Darren Hoo]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

HI Jan,

Sorry, your fix is right, just ignore my last mail.

On Sun, Oct 20, 2013 at 2:58 AM, Darren Hoo <darren.hoo@gmail.com> wrote:

> On Fri, Oct 18, 2013 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > What about my questions about the "Services" menu?  I don't think you
> > answered those.
>
> Thanks chad for explaining what  services menu for me.
>
> Jan,
>
> your  114716 commit totally removes the services menu. But I think some
> GUI
> users may use it, I sometimes use it while not quite often.
>
> How about bring it back? I have tested the following patch on OSX,
> While I tried Emacs on GNUStep it crashes , but I don't think the crash is
> related to this.
>
> I am curious that how many users use Emacs on GNUStep nowadays?
>

[-- Attachment #2: Type: text/html, Size: 1294 bytes --]

Re: Input for TTY menus

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

Hello.

19 okt 2013 kl. 21:07 skrev Darren Hoo <darren.hoo@gmail.com>:

> HI Jan,
> 
> Sorry, your fix is right, just ignore my last mail.
> 

Actually you have a point, services do exist for GNUStep GUI version, so the menu item should be there, but not when running in a terminal.

I have made changes to this effect in trunk.

> On Sun, Oct 20, 2013 at 2:58 AM, Darren Hoo <darren.hoo@gmail.com> wrote:
> On Fri, Oct 18, 2013 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > What about my questions about the "Services" menu?  I don't think you
> > answered those.
> 
> Thanks chad for explaining what  services menu for me.
> 
> Jan,
> 
> your  114716 commit totally removes the services menu. But I think some GUI 
> users may use it, I sometimes use it while not quite often.
> 
> How about bring it back? I have tested the following patch on OSX, 
> While I tried Emacs on GNUStep it crashes , but I don't think the crash is 
> related to this.

GNUStep installation is a mess, there are font issues, you must choose the correct backend, and there is lots of bugs.  I only get acceptable results when running GNUStep 0.21 or newer on Fedora 18 or newer.  Mint/Ubuntu for example is a no-go regardless of version of GNUStep.

> 
> I am curious that how many users use Emacs on GNUStep nowadays?
> 

No idea, might be just me :-).  But it is a GNU-project, thats the main reason it is supported.

	Jan D.


[-- Attachment #2: Type: text/html, Size: 3133 bytes --]

Re: Input for TTY menus

[Eli Zaretskii]

> Date: Fri, 18 Oct 2013 09:49:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > 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?

Re: Input for TTY menus

[Stefan Monnier]

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

Can you describe what you did?  AFAICT, you clicked on "Edit" first, and
then in the end you clicked on "Goto line...", and I gues in the middle
you clicked on "Go To".  Not sure why we only see 2 clicks above.

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

Which event queue?
Also, isn't it possible that you have not yet released the mouse button
when you try to remove those mouse events?

> and on top of that, menu-bar.el binds mouse-1 to tty-menu-ignore.

But only while the menu is displayed.  After selecting "Goto line..."
(which seems to happen on the down-mouse-1 event) you pop down the menu
and you don't use the special map any more.

You might like to change the way your menus work so that it is the
up-mouse (i.e. mouse-1) which performs the action and the down-mouse
which are ignored.

Of course, the first up-mouse event should be ignored if it happens very
soon after the menu was popped up (and at about the same place as the
down-mouse that triggered the menu).


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: darren.hoo@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 18 Oct 2013 11:12:51 -0400
> 
> > 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>
> 
> Can you describe what you did?  AFAICT, you clicked on "Edit" first, and
> then in the end you clicked on "Goto line...", and I gues in the middle
> you clicked on "Go To".  Not sure why we only see 2 clicks above.

Instead of clicking "Edit" on the menu bar, I clicked C-mouse-3 on the
text area of a buffer that is in Fundamental mode; that pops up the
"Edit" menu.  The complete trace is this:

  <C-mouse-3> <mouse-movement> <mouse-movement> <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,
> 
> Which event queue?

I call discard_mouse_events.

> Also, isn't it possible that you have not yet released the mouse button
> when you try to remove those mouse events?

Could be.

> > and on top of that, menu-bar.el binds mouse-1 to tty-menu-ignore.
> 
> But only while the menu is displayed.  After selecting "Goto line..."
> (which seems to happen on the down-mouse-1 event) you pop down the menu
> and you don't use the special map any more.
> 
> You might like to change the way your menus work so that it is the
> up-mouse (i.e. mouse-1) which performs the action and the down-mouse
> which are ignored.

I will see what I can do, thanks.

> Of course, the first up-mouse event should be ignored if it happens very
> soon after the menu was popped up (and at about the same place as the
> down-mouse that triggered the menu).

Why is that?

Re: Input for TTY menus

[Stefan Monnier]

>> Of course, the first up-mouse event should be ignored if it happens very
>> soon after the menu was popped up (and at about the same place as the
>> down-mouse that triggered the menu).
> Why is that?

That's for the case where the menu was popped up in response to
a down-mouse event.  In that case, if that down-mouse was "part of
a click" we should ignore the subsequent up-mouse, but if instead the
user does "press mouse-1, move to element, release mouse-1" then
we don't want to ignore the up-mouse.


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 18 Oct 2013 11:12:51 -0400
> Cc: emacs-devel@gnu.org, darren.hoo@gmail.com
> 
> You might like to change the way your menus work so that it is the
> up-mouse (i.e. mouse-1) which performs the action and the down-mouse
> which are ignored.

Thanks, this seems to work well, so I installed the change as trunk
revision 114717.

> Of course, the first up-mouse event should be ignored if it happens very
> soon after the menu was popped up (and at about the same place as the
> down-mouse that triggered the menu).
> 
> That's for the case where the menu was popped up in response to
> a down-mouse event.  In that case, if that down-mouse was "part of
> a click" we should ignore the subsequent up-mouse, but if instead the
> user does "press mouse-1, move to element, release mouse-1" then
> we don't want to ignore the up-mouse.

Dragging the mouse right after popping up the menu and releasing it to
select a menu item is very rare.  After the above change, indeed in
some cases releasing the mouse after dragging it does not select the
menu item, you need another click.  But I consider this a very rare
situation, and the remedy is simple and natural: click once more.  So
I didn't do anything about this case.

Re: Input for TTY menus

[Stefan Monnier]

> Dragging the mouse right after popping up the menu and releasing it to
> select a menu item is very rare.

For some users, it is the standard way to use menus.

> After the above change, indeed in some cases releasing the mouse after
> dragging it does not select the menu item, you need another click.

IIUC you always (try to) discard the initial up-mouse event.

> But I consider this a very rare situation, and the remedy is simple
> and natural: click once more.  So I didn't do anything about
> this case.

It's probably OK for now: with the current tty-menu code, the
"press-move-release" usage does not work for entries in submenus anyway.


        Stefan

Re: Input for TTY menus

[chad]

On 17 Oct 2013, at 23:49, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> Where does the "Services" item come from on NS?  It's not present on
> other systems, AFAICS.

NS apps have a standard menu entry in their application menu for
system- and user-created functions to be added. These vary by context
and activity (for example, you can create services that appear only
when you have certain kinds of things selected, are in certain kinds
of applications, etc).

Both gui and terminal emacs under NS have a services menu, but only
the gui NS emacs is correctly populating it from the system. It
seems to be created in nsterm.m:ns_term_init() when the application
menu is created (look for svcsMenu).

> Also, if you invoke tmm-menubar with M-`, does the Services item
> appear there, and if so, can it be selected and used as you'd expect?

It tmm-menu does have a Services item, and it's empty there also.

At a guess, the NS port is creating a stub for the menubar, and
then moving it into the application menu in some NS gui-only code.

Hope that helps,
~Chad

Re: Input for TTY menus

[chad]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On 18 Oct 2013, at 10:41, chad <yandros@mit.edu> wrote:

> On 17 Oct 2013, at 23:49, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> Where does the "Services" item come from on NS?  It's not present on
>> other systems, AFAICS.
> 
> NS apps have a standard menu entry in their application menu for
> system- and user-created functions to be added. These vary by context
> and activity (for example, you can create services that appear only
> when you have certain kinds of things selected, are in certain kinds
> of applications, etc).

Whoops; I meant to include this example from gui NS emacs:


~Chad


[-- Attachment #2.1: Type: text/html, Size: 1274 bytes --]

[-- Attachment #2.2: Screen Shot 2013-10-18 at 10.26.33.png --]
[-- Type: image/png, Size: 80210 bytes --]

Re: Input for TTY menus

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Fri, 18 Oct 2013 10:41:33 -0700
> Cc: Darren Hoo <darren.hoo@gmail.com>, emacs-devel@gnu.org
> 
> Both gui and terminal emacs under NS have a services menu, but only
> the gui NS emacs is correctly populating it from the system. It
> seems to be created in nsterm.m:ns_term_init() when the application
> menu is created (look for svcsMenu).
> 
> > Also, if you invoke tmm-menubar with M-`, does the Services item
> > appear there, and if so, can it be selected and used as you'd expect?
> 
> It tmm-menu does have a Services item, and it's empty there also.

Thanks for explaining and for testing.

> At a guess, the NS port is creating a stub for the menubar, and
> then moving it into the application menu in some NS gui-only code.

I see something in nsfns.m.  Perhaps some NS person could look into
fixing this.

Re: Input for TTY menus

[Jan Djärv]

Hello. 

18 okt 2013 kl. 20:14 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: chad <yandros@MIT.EDU>
>> Date: Fri, 18 Oct 2013 10:41:33 -0700
>> Cc: Darren Hoo <darren.hoo@gmail.com>, emacs-devel@gnu.org
>> 
>> Both gui and terminal emacs under NS have a services menu, but only
>> the gui NS emacs is correctly populating it from the system. It
>> seems to be created in nsterm.m:ns_term_init() when the application
>> menu is created (look for svcsMenu).
>> 
>>> Also, if you invoke tmm-menubar with M-`, does the Services item
>>> appear there, and if so, can it be selected and used as you'd expect?
>> 
>> It tmm-menu does have a Services item, and it's empty there also.
> 
> Thanks for explaining and for testing.
> 
>> At a guess, the NS port is creating a stub for the menubar, and
>> then moving it into the application menu in some NS gui-only code.
> 
> I see something in nsfns.m.  Perhaps some NS person could look into
> fixing this.

The service menu can not be populated in a non-gui session. I'll check if we can remove it. 

    Jan D. 

Re: Input for TTY menus

[Stefan Monnier]

>> Both gui and terminal emacs under NS have a services menu, but only
>> the gui NS emacs is correctly populating it from the system. It
>> seems to be created in nsterm.m:ns_term_init() when the application
>> menu is created (look for svcsMenu).
>> > Also, if you invoke tmm-menubar with M-`, does the Services item
>> > appear there, and if so, can it be selected and used as you'd expect?
>> It tmm-menu does have a Services item, and it's empty there also.
> Thanks for explaining and for testing.

It sounds like there's a bug in the NS code: the menu should probably
either not exist under a tty, or be filled with appropriate elements.

>> At a guess, the NS port is creating a stub for the menubar, and
>> then moving it into the application menu in some NS gui-only code.
> I see something in nsfns.m.  Perhaps some NS person could look into
> fixing this.

But the tty-menu code should also correctly handle an empty menu.
E.g. if I do:

emacs -Q -nw
M-: (global-set-key [menu-bar test] '(menu-item "Test" (keymap "Test"))) RET
f10

then f10 just tells me "Empty menu" and doesn't let me move to
another menu.


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: chad <yandros@mit.edu>, emacs-devel@gnu.org, darren.hoo@gmail.com
> Date: Fri, 18 Oct 2013 16:04:54 -0400
> 
> But the tty-menu code should also correctly handle an empty menu.
> E.g. if I do:
> 
> emacs -Q -nw
> M-: (global-set-key [menu-bar test] '(menu-item "Test" (keymap "Test"))) RET
> f10
> 
> then f10 just tells me "Empty menu" and doesn't let me move to
> another menu.

I'd appreciate if you or someone else could fix this, or describe the
solution in enough detail that I could do it myself.  Keymaps and
input in general is an area in Emacs where I know very little, and I
already spent a disproportional amount of time on that aspect of the
menus (for comparison, the display aspects of the menus started
working within 2 working days of the code completion).

Re: Input for TTY menus

[Eli Zaretskii]

> Date: Sat, 19 Oct 2013 10:35:20 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: yandros@mit.edu, darren.hoo@gmail.com, emacs-devel@gnu.org
> 
> > From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> > Cc: chad <yandros@mit.edu>, emacs-devel@gnu.org, darren.hoo@gmail.com
> > Date: Fri, 18 Oct 2013 16:04:54 -0400
> > 
> > But the tty-menu code should also correctly handle an empty menu.
> > E.g. if I do:
> > 
> > emacs -Q -nw
> > M-: (global-set-key [menu-bar test] '(menu-item "Test" (keymap "Test"))) RET
> > f10
> > 
> > then f10 just tells me "Empty menu" and doesn't let me move to
> > another menu.
> 
> I'd appreciate if you or someone else could fix this, or describe the
> solution in enough detail that I could do it myself.  Keymaps and
> input in general is an area in Emacs where I know very little, and I
> already spent a disproportional amount of time on that aspect of the
> menus (for comparison, the display aspects of the menus started
> working within 2 working days of the code completion).

I can propose the following kludge-around:

=== modified file 'src/term.c'
--- src/term.c	2013-10-17 06:42:21 +0000
+++ src/term.c	2013-10-19 09:37:15 +0000
@@ -3607,8 +3607,8 @@ tty_menu_show (struct frame *f, int x, i
 
   if (menu_items_used <= MENU_ITEMS_PANE_LENGTH)
     {
-      *error_name = "Empty menu";
-      return Qnil;
+      tty_menu_new_item_coords (f, TTYM_NEXT, &x, &y);
+      return Fcons (make_number (x), make_number (y));
     }
 
   /* Make the menu on that window.  */


The problem with this is that this change arbitrarily switches to the
next menu-bar menu, which means that if you use C-b or left-arrow to
move backwards through the menu-bar items, you will be "stuck" when
you get to the empty menu item.  IOW, you can only move past such an
empty menu while moving forward (C-f or right-arrow).

However, if this is deemed "good enough", I will install it.

Btw, what does the non-toolkit menu do with this situation on X, when
triggered by F10?  Doesn't it behave the same?

Re: Input for TTY menus

[Stefan Monnier]

> The problem with this is that this change arbitrarily switches to the
> next menu-bar menu, which means that if you use C-b or left-arrow to
> move backwards through the menu-bar items, you will be "stuck" when
> you get to the empty menu item.  IOW, you can only move past such an
> empty menu while moving forward (C-f or right-arrow).

It's better, but still not really satisfactory.

> However, if this is deemed "good enough", I will install it.

How 'bout we fall back on a default "empty menu", instead?

> Btw, what does the non-toolkit menu do with this situation on X, when
> triggered by F10?  Doesn't it behave the same?

It might do the exact same thing, indeed, but the tty menus are much
more often used with f10 than the non-toolkit menu which is more often
used with the mouse (where this problem is not very significant).


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yandros@mit.edu,  darren.hoo@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 19 Oct 2013 09:40:34 -0400
> 
> > The problem with this is that this change arbitrarily switches to the
> > next menu-bar menu, which means that if you use C-b or left-arrow to
> > move backwards through the menu-bar items, you will be "stuck" when
> > you get to the empty menu item.  IOW, you can only move past such an
> > empty menu while moving forward (C-f or right-arrow).
> 
> It's better, but still not really satisfactory.
> 
> > However, if this is deemed "good enough", I will install it.
> 
> How 'bout we fall back on a default "empty menu", instead?

Not sure what that means, please elaborate.

Re: Input for TTY menus

[Stefan Monnier]

>> How 'bout we fall back on a default "empty menu", instead?
> Not sure what that means, please elaborate.

Instead of using the menu provided (which is "too empty" to be able to
provide a good behavior), use another, predefined, "empty" menu.


        Stefan

Re: Input for TTY menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yandros@mit.edu,  darren.hoo@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 19 Oct 2013 11:25:44 -0400
> 
> >> How 'bout we fall back on a default "empty menu", instead?
> > Not sure what that means, please elaborate.
> 
> Instead of using the menu provided (which is "too empty" to be able to
> provide a good behavior), use another, predefined, "empty" menu.

Sorry, I don't know how to prepare such an empty menu.

Re: Input for TTY menus

[Jan Djärv]

Hello.

I removed Services menu from menu-bar.el, it does not make any sense in that context.

	Jan D.

18 okt 2013 kl. 20:14 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: chad <yandros@MIT.EDU>
>> Date: Fri, 18 Oct 2013 10:41:33 -0700
>> Cc: Darren Hoo <darren.hoo@gmail.com>, emacs-devel@gnu.org
>> 
>> Both gui and terminal emacs under NS have a services menu, but only
>> the gui NS emacs is correctly populating it from the system. It
>> seems to be created in nsterm.m:ns_term_init() when the application
>> menu is created (look for svcsMenu).
>> 
>>> Also, if you invoke tmm-menubar with M-`, does the Services item
>>> appear there, and if so, can it be selected and used as you'd expect?
>> 
>> It tmm-menu does have a Services item, and it's empty there also.
> 
> Thanks for explaining and for testing.
> 
>> At a guess, the NS port is creating a stub for the menubar, and
>> then moving it into the application menu in some NS gui-only code.
> 
> I see something in nsfns.m.  Perhaps some NS person could look into
> fixing this.

Re: Input for TTY menus

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 19 Oct 2013 10:58:19 +0200
> Cc: chad <yandros@MIT.EDU>,
>  emacs-devel@gnu.org,
>  darren.hoo@gmail.com
> 
> I removed Services menu from menu-bar.el, it does not make any sense in that context.

Thanks.