From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Menus with more items than the TTY can display Date: Sun, 20 Oct 2013 19:38:16 +0300 Message-ID: <83fvrvlwxz.fsf@gnu.org> References: <83a9igrqq1.fsf@gnu.org> <5257E3B3.4070508@yandex.ru> <834n8nswas.fsf@gnu.org> <831u3nrhf9.fsf@gnu.org> <525D8938.6080208@gmx.at> <83hacipd88.fsf@gnu.org> <525E43D8.6060109@gmx.at> <83bo2pp7kd.fsf@gnu.org> <525ED0CE.9010001@gmx.at> <834n8hozdu.fsf@gnu.org> <525EDC1A.9070201@gmx.at> <83y55tnii4.fsf@gnu.org> <525FADCF.5010700@gmx.at> <83ob6nonry.fsf@gnu.org> <52601ACA.9070603@gmx.at> <83iowvokoj.fsf@gnu.org> <526025E8.20009@gmx.at> <83fvrzoe6o.fsf@gnu.org> <83eh7joda2.fsf@gnu.org> <5260E981.6020604@gmx.at> <8361suorfj.fsf@gnu.org> <52614739.9040901@gmx.at> <83ob6mmw9j.fsf@gnu.org> <83k3hamlr5.fsf@gnu.org> <5262613C.1020207@gmx.at> <83zjq5lbmu.fsf@gnu.org> <52628FDA.6050502@gmx.at> <83vc0tl34r.fsf@gnu.org> <83txgdkz5y.fsf@gnu.org> <5262D122.3040709@gmx.at> <83ppr1kr6q.fsf@gnu.org> <5263AE6E.7010300@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1382287101 27734 80.91.229.3 (20 Oct 2013 16:38:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2013 16:38:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 20 18:38:24 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VXw1F-00084B-VP for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2013 18:38:22 +0200 Original-Received: from localhost ([::1]:36903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXw1F-0007BK-KD for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2013 12:38:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXw18-0007BB-Cp for emacs-devel@gnu.org; Sun, 20 Oct 2013 12:38:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXw13-0001Nj-6E for emacs-devel@gnu.org; Sun, 20 Oct 2013 12:38:14 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:60643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXw12-0001Nd-Ts for emacs-devel@gnu.org; Sun, 20 Oct 2013 12:38:09 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MUZ00H007G3CF00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sun, 20 Oct 2013 19:38:07 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MUZ00HQQ7JI9K40@a-mtaout23.012.net.il>; Sun, 20 Oct 2013 19:38:07 +0300 (IDT) In-reply-to: <5263AE6E.7010300@gmx.at> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164395 Archived-At: > Date: Sun, 20 Oct 2013 12:20:30 +0200 > From: martin rudalics > CC: emacs-devel@gnu.org > > > 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.