Re: Menus with more items than the TTY can display

[Eli Zaretskii]

> Date: Sun, 20 Oct 2013 12:20:30 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > Examples?  Are those per chance the cases where Emacs writes only part
>  > of the new line, because it shared some characters with the old one?
>  > Like when Emacs needs to replace "Foobar" with "Foobaz", and writes
>  > only "baz" starting at the 4th character?
> 
> I can't remember but it's possible.  Unfortunately, I can't reproduce it
> currently very well.  The attached screenshot is not representative of
> what I mean.  It shows that the help echo "Insert ..." can start before
> the position where the menu ends but there's already some other gruft
> before it.  Believe me that I've seen an echo area where text like "rate
> on its file" doesn't appear but the first help echo is written out
> correctly, followed by some spaces, followed by the second help echo
> written out correctly and the second help echo does not align with the
> right border of the menu but starts on the left of it.

I believe this happens when Emacs deletes and inserts characters on
the current line to optimize its screen writes.  Emacs does that when
the current and the desired contents of a screen line share some
characters at the beginning and/or at the end.

> Reproducing things reliably is practically impossible.  Somehow, the
> state after killing a terminal or terminating emacs in it seems to
> affect the next invocation of the terminal and/or emacs.

Too bad, as this might play nasty games with our minds.

Anyway, I've analyzed the termscript files you've posted.  At least
some of the differences are due to the fact that you set
resize-mini-windows by evaluating the setq form in the *scratch*
buffer.  That has the side effect of starting the menu display with
the cursor in a position that is different from when you start the
menu right after entering Emacs.  The crucial difference is that in
the latter case, the cursor is at the leftmost column, so many cursor
addressing commands omit the x coordinate, assuming that the terminal
will keep the column address while changing only the row.

The next request might sound silly, but please humor me.  Please
repeat the experiment with setting resize-mini-windows to nil, and
with the original 22/21.0 frame size, but this time set
resize-mini-windows via M-:, and make sure the cursor is in the same
position as when you enter Emacs.  Please do the same 10 presses on
the down arrow key as you did before, so that I could compare the
termscripts again.  I expect the termscripts to be identical in this
case.

Note that I half expect the magical resize-mini-windows effect to
disappear, when you do the above, i.e. I expect you to see the problem
even with resize-mini-windows nil.  If this is indeed so, it is a Good
Thing, because I cannot imagine any relation between that variable and
what you see.

Finally, after you do all that, please comment out the line marked
below at the end of tty_menu_display, recompile, and see if the
problem persists.

        display_tty_menu_item (menu->text[j], max_width, face, x, y + i,
                               menu->submenu[j] != NULL);
      }
    update_frame_with_menu (sf);
    cursor_to (sf, row, col);  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  }

Thanks.