GNU bug report logs - #17497
24.4.50; TTY menu glitches

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17497 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, dickey <at> his.com
Subject: bug#17497: 24.4.50; TTY menu glitches
Date: Wed, 04 Jun 2014 20:10:50 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Thomas Dickey <dickey <at> his.com>,  monnier <at> iro.umontreal.ca,  17497 <at> debbugs.gnu.org
> Date: Wed, 04 Jun 2014 12:09:26 -0400
> 
> Eli Zaretskii wrote:
> 
> > On the hunch that the problems discussed here are caused by excess
> > movement of the cursor, I've made changes in revision 117203 on the
> > emacs-24 branch to avoid some of them.  Please try that.
> 
> Sorry, still glitches. :(

If you put a breakpoint in update_frame and in update_frame_with_menu,
like shown below, how many calls do you see when you press an arrow
key (or C-n/C-p) that produces a glitch?  I expect 1 call to
update_frame_with_menu followed by one call to update_frame.  Here's a
GDB session on fencepost to show what I see:

  (gdb) break update_frame
  Breakpoint 1 at 0x41b605: file dispnew.c, line 3006.
  (gdb) commands
  Type commands for breakpoint(s) 3, one per line.
  End with a line saying just "end".
  >continue
  >end
  (gdb) break update_frame_with_menu
  Breakpoint 2 at 0x41b81b: file dispnew.c, line 3112.
  (gdb) commands
  Type commands for breakpoint(s) 4, one per line.
  End with a line saying just "end".
  >continue
  >end
  (gdb) c
  Continuing.

  Breakpoint 1, update_frame (f=0xd3e808, force_p=false, 
      inhibit_hairy_id_p=false) at dispnew.c:3006
  3006	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=-1, col=-1)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=0, col=0)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=1, col=0)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
      at dispnew.c:3006
  3006	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=2, col=0)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
      at dispnew.c:3006
  3006	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=3, col=0)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
      at dispnew.c:3006
  3006	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 2, update_frame_with_menu (f=0xd3e808, row=2, col=0)
      at dispnew.c:3112
  3112	  struct window *root_window = XWINDOW (f->root_window);

  Breakpoint 1, update_frame (f=0xd3e808, force_p=true, inhibit_hairy_id_p=true)
      at dispnew.c:3006
  3006	  struct window *root_window = XWINDOW (f->root_window);

Explanations:

 . first, a call to update_frame is because menu-bar-open calls
   'redisplay'

 . next, a call to update_frame_with_menu which comes from
   the beginning of tty_menu_activate, line 3230 of term.c

 . another call to update_frame_with_menu, to display the "File >"
   header of the File menu.

 . yet another call to update_frame_with_menu to display the first
   menu item (Visit New File) in red background

 . finally, a call to update_frame to display the help-echo for "Visit
   New File"

Thereafter, for each keypress of an arrow key, there's always 1 call
to update_frame_with_menu, to display a different menu item in the red
background (see the values of row and col arguments, which identify
the menu item), followed by a single call to update_frame to display
the help echo.

Do you see any calls to update_frame beyond what I described?  If so,
perhaps they are the reason the cursor gets back to the EOB of the
underlying buffer.

TIA

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.