bug#17497: 24.4.50; TTY menu glitches

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 01 Jun 2014 15:46:00 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: dickey@his.com, 17497@debbugs.gnu.org
> 
> > So buffering output more aggressively could help, is that what you are
> > saying?
> > 
> > We currently fflush the stream every 900 bytes and also every 10
> > screen lines or so.  Does that sound reasonable?
> 
> I don't think that will be enough: the output stream simply is not fast
> enough to keep up.

That'd be strange, since it evidently does succeed to keep up when we
redraw the display "normally", i.e. not due to dropping down or
updating a menu.

Anyway, I took another look at all the screenshots posted in this bug
report, and my conclusion is that all of the artifacts seem to be
caused by 2 root causes:

  . Incorrect position of the cursor when a menu item is redrawn.

    This explains why some menu items are "duplicated" elsewhere in
    the menu, and also why items that needed to be redrawn with blue
    background (i.e. in the "non-selected" face) are left with the red
    background of the "selected" face.

    In all of these cases, it looks like the cursor was positioned at
    the EOB of the buffer (*scratch*) displayed beneath the menu.
    This is the "normal" cursor position, as Emacs perceives it, and
    that's where redisplay leaves the cursor after updating the frame
    display.  We override that in the menu-display code, by sending a
    cursor motion command after the frame is completely displayed; it
    looks like in at least some of the cases this cursor motion
    command was not obeyed.

  . The insert mode is not turned off before some string is written to
    the display.

    This explains why we see menu items to the right of the menu: they
    were "pushed" by writing some other text to their left, while in
    insert mode.  There are similar problems in some of the
    screenshots with the help-echo displayed in the echo area.

    Alternatively, this type of artifacts can also be explained by
    incorrect cursor position in the horizontal axis.  To decide which
    explanation is correct, I'd need to see the artifacts when the
    underlying window is full of some buffer text, not almost empty as
    in *scratch*.  Glenn, could I persuade you to try that and show
    the screenshots?

Does the above ring any bells?

Please also note that Emacs tries to be "clever" about cursor motion
on a TTY: it chooses out of several possible methods of moving the
cursor, comparing their "costs" (see cm.c:cmgoto for details).  So
it's possible that different cursor movements emit different commands
to the terminal driver, and somehow trigger these strange effects.

Finally, one difference between the "normal" screen update and the one
we use to display and update TTY menus is that the latter seems to
cause significantly more cursor motion.  One possible way to cut down
on that is to set show-help-function to nil.  Glenn, can I ask you to
try that and see if it helps in any way?

TIA