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

Previous Next

Package: emacs;

Reported by: Dmitry Antipov <dmantipov <at> yandex.ru>

Date: Thu, 15 May 2014 12:28:01 UTC

Severity: normal

Tags: patch

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Thomas Dickey <dickey <at> his.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17497 <at> debbugs.gnu.org, dickey <at> his.com
Subject: bug#17497: 24.4.50; TTY menu glitches
Date: Sun, 01 Jun 2014 15:46:00 -0400
[Message part 1 (text/plain, inline)]
On Sun, Jun 01, 2014 at 09:45:07PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 01 Jun 2014 13:18:17 -0400
> > From: Thomas Dickey <dickey <at> his.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 17497 <at> debbugs.gnu.org
> > 
> > What ncurses does when it's getting behind is to drop updates - the
> > typeahead feature:
> > 
> >        The  curses  library does ``line-breakout optimization'' by looking for
> >        typeahead periodically while updating the screen.  If input  is  found,
> >        and  it is coming from a tty, the current update is postponed until re-
> >        fresh or doupdate is called again.  This allows faster response to com-
> >        mands  typed  in  advance.   Normally, the input FILE pointer passed to
> >        newterm, or stdin in the case that initscr was used, will be used to do
> >        this typeahead checking.  The typeahead routine specifies that the file
> >        descriptor fd is to be used to check for typeahead instead.  If  fd  is
> >        -1, then no typeahead checking is done.
> 
> 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.  The typeahead feature is crude, but works.  A more
elegant approach (perhaps complicated) would be to keep track of the
changes since the beginning of a repaint, and store _those_ into a
buffer which could be discarded if it is not written before the next
input character is detected.

-- 
Thomas E. Dickey <dickey <at> invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 5 years and 338 days ago.

Previous Next


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