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 09:49:22 +0300

> Date: Fri, 18 Oct 2013 12:55:59 +0800
> From: Darren Hoo <address@hidden>
> Cc: emacs-devel <address@hidden>
> 
> > 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);




reply via email to

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