emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Menus with more items than the TTY can display


From: Eli Zaretskii
Subject: Re: Menus with more items than the TTY can display
Date: Mon, 21 Oct 2013 19:42:01 +0300

> Date: Mon, 21 Oct 2013 09:19:16 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden
> 
>  > So, to summarize what we discovered until now:
>  >
>  >   . The problem seems to happen because, for some reason, the cursor
>  >     does not keep its horizontal coordinate, and Emacs is not aware of
>  >     that.  If cursor motion commands emitted by Emacs explicitly
>  >     specify an x-coordinate, the problem disappears.
> 
> For the problem to occur, the cursor must be at a leftmost position of
> the frame, regardless of whether it's in the (possibly split) root
> window or the echo area.
> 
>  >   . This seems to happen only when output is delivered at high rate to
>  >     the screen, and seems to disappear when output is slowed down,
>  >     e.g. by hitting GDB breakpoints, even if their commands
>  >     immediately continue the debuggee.
>  >
>  >   . Enlarging the frame by merely 2 lines, to 26 lines overall, makes
>  >     the problem disappear.
> 
> Changing the number of columns of the frame does not seem to have any
> impact.
> 
>  >   . Faces used to display the menus don't have any effect on the
>  >     problem.
>  >
>  > Anything else?
> 
> The problem manifests itself with fonts larger than 10 pts.  With fonts
> less equal 10 pts the problem does not occur.

Thanks.

So before we file this under "weird problem with a couple of simple
work-arounds", can I please ask you to produce one last termscript --
when the frame has 26 lines (i.e. the problem should not happen), when
you do those same 10 keystrokes?  I'd like to make sure the commands
we send to the terminal in that case are identical, except for the
obvious differences due to higher window.

TIA



reply via email to

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