From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17497: 24.4.50; TTY menu glitches Date: Sun, 01 Jun 2014 19:25:29 +0300 Message-ID: <838upgbnra.fsf@gnu.org> References: <83vbslbuqr.fsf@gnu.org> <20140531200947.GA779@aerie.jexium-island.net> <83lhtgbrd6.fsf@gnu.org> <20140601152657.GA15078@aerie.jexium-island.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1401639994 15309 80.91.229.3 (1 Jun 2014 16:26:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Jun 2014 16:26:34 +0000 (UTC) Cc: 17497@debbugs.gnu.org To: dickey@his.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 01 18:26:27 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wr8aX-00037o-Pu for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Jun 2014 18:26:26 +0200 Original-Received: from localhost ([::1]:41407 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr8aX-000536-CB for geb-bug-gnu-emacs@m.gmane.org; Sun, 01 Jun 2014 12:26:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr8aF-0004jB-Ky for bug-gnu-emacs@gnu.org; Sun, 01 Jun 2014 12:26:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wr8aA-0004YO-JX for bug-gnu-emacs@gnu.org; Sun, 01 Jun 2014 12:26:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wr8aA-0004YI-Ga for bug-gnu-emacs@gnu.org; Sun, 01 Jun 2014 12:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wr8a9-00036N-Tu for bug-gnu-emacs@gnu.org; Sun, 01 Jun 2014 12:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 01 Jun 2014 16:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17497 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17497-submit@debbugs.gnu.org id=B17497.140163995311898 (code B ref 17497); Sun, 01 Jun 2014 16:26:01 +0000 Original-Received: (at 17497) by debbugs.gnu.org; 1 Jun 2014 16:25:53 +0000 Original-Received: from localhost ([127.0.0.1]:40019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wr8a0-00035n-9g for submit@debbugs.gnu.org; Sun, 01 Jun 2014 12:25:52 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:64338) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wr8Zv-00035K-RM for 17497@debbugs.gnu.org; Sun, 01 Jun 2014 12:25:49 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N6I00G0005STY00@a-mtaout22.012.net.il> for 17497@debbugs.gnu.org; Sun, 01 Jun 2014 19:25:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6I00GNQ0ASP210@a-mtaout22.012.net.il>; Sun, 01 Jun 2014 19:25:41 +0300 (IDT) In-reply-to: <20140601152657.GA15078@aerie.jexium-island.net> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:89863 Archived-At: [I asked Thomas for his expert opinion on this strange issue, and he graciously agreed.] > Date: Sun, 01 Jun 2014 11:26:57 -0400 > From: Thomas Dickey > Cc: dickey@his.com > > On Sun, Jun 01, 2014 at 06:07:33PM +0300, Eli Zaretskii wrote: > > > Date: Sat, 31 May 2014 16:09:47 -0400 > > > From: Thomas Dickey > > > Cc: dickey@his.com > > > > > > The discussion sounds like a common problem: terminals send cursor- and > > > function-keys generally as a sequence of bytes, requiring an application > > > to wait for each sequence to complete. If each keystroke causes the > > > application to do something that writes a lot of text to the screen (such > > > as scrolling), it's possible to have some of those sequences timeout. > > > Once that happens, the application doesn't see cursor-keys, it sees the > > > individual bytes - which can be interpreted differently (including echoing > > > and further messing up the display). > > > > > > While I'm aware that Emacs doesn't use ncurses for screen optimization, > > > which is the same issue implied in the description of ESCDELAY in the > > > ncurses manpage, which begins > > > > > > ESCDELAY > > > Specifies the total time, in milliseconds, for which ncurses > > > will await a character sequence, e.g., a function key. The > > > default value, 1000 milliseconds, is enough for most uses. > > > However, it is made a variable to accommodate unusual applica‐ > > > tions. > > > > > > The most common instance where you may wish to change this > > > value is to work with slow hosts, e.g., running on a network. > > > If the host cannot read characters rapidly enough, it will > > > have the same effect as if the terminal did not send charac‐ > > > ters rapidly enough. The library will still see a timeout. > > > > Thanks. > > > > However, what puzzles me is that the code which implements text-mode > > menus doesn't change at all how Emacs handles display on a TTY. We > > just overwrite portions of the display with the menu text in some > > internal data structure, then hand out that structure to the code > > which updates the screen, as if the buffer text has changed. So how > > come we never saw similar problems with normal Emacs display on a TTY, > > e.g. when the user presses PgDn to scroll the text? > > Scrolling one line at a time versus scrolling the whole page differs > most noticeably if the application doesn't (or can't) use a terminal's > scrolling features. If it doesn't scroll, then the whole screen has to > be repainted for each update. Emacs optimizes redrawing by comparing the previous and the desired display, and then only repainting the changed parts. None of that changes when the menu is displayed, we just overwrite portions of the desired display data structure, then call the normal redrawing routines. That's why it puzzles me why the problems are being reported only for the menus. > Repainting the screen after scrolling one line is going to be much slower > than repainting the screen after scrolling one page. Yes, I understand. But repainting the menu when the user presses, e.g., the down arrow, is no different: Emacs just repaints the previously-selected menu item in the normal color, then repaints the one below it in the "selected" color. (Actually, since the menu item is usually shorter than the terminal width, only part of each of those 2 lines is redrawn.) > > Btw, is it OK to CC the Emacs bug tracker, so that this discussion is > > recorded there? > > yes Thanks. The 17497@debbugs.gnu.org address above will achieve that.