From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup Date: Wed, 28 Jun 2017 19:48:14 +0300 Message-ID: <83r2y4qcs1.fsf@gnu.org> References: <611468a0-3115-813a-7347-d0c06e155831@web.de> <83vanrx5uo.fsf@gnu.org> <362a7d18-7f05-2e99-f8b3-41c353cf234f@yandex.ru> <83h8zawvih.fsf@gnu.org> <00f59a24-2d80-ca47-b6f3-3d219aa5aa3f@yandex.ru> <8360fqvz9x.fsf@gnu.org> <6aa4616d-79f7-db1b-c048-076a9a48596f@yandex.ru> <83tw39urzq.fsf@gnu.org> <4c4b873b-2bec-1c12-82f5-325b558bea93@yandex.ru> <83o9tgul6h.fsf@gnu.org> <49b431fd-aaa4-e7ca-06fc-7146a0a5692c@yandex.ru> <83a84zul0d.fsf@gnu.org> <513eca6f-998a-a937-76c4-7cf2fb0ff787@yandex.ru> <83wp81u8rz.fsf@gnu.org> <8ec1b301-79dc-7d11-b3f9-85ae2e925785@yandex.ru> <594FDDC5.6040009@gmx.at> <83zicwrkmu.fsf@gnu.org> <5950C342.7010908@gmx.at> <83mv8ussb6.fsf@gnu.org> <595203DE.1040608@gmx.at> <837ezxsd02.fsf@gnu.org> <59527971.5000205@gmx.at> <83y3sdqtto.fsf@gnu.org> <59536CA6.10608@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1498668553 17118 195.159.176.226 (28 Jun 2017 16:49:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Jun 2017 16:49:13 +0000 (UTC) Cc: alexanderm@web.de, 27427@debbugs.gnu.org, dgutov@yandex.ru To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 28 18:49:09 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQG9M-00043G-UT for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 18:49:09 +0200 Original-Received: from localhost ([::1]:34357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQG9S-0000DK-39 for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 12:49:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQG9H-00006R-2H for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 12:49:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQG9G-00053f-1W for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 12:49:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40155) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dQG9F-00053Y-Ul for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 12:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dQG9F-0008Fa-OS for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 12:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Jun 2017 16:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27427 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27427-submit@debbugs.gnu.org id=B27427.149866852931694 (code B ref 27427); Wed, 28 Jun 2017 16:49:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 28 Jun 2017 16:48:49 +0000 Original-Received: from localhost ([127.0.0.1]:42832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQG92-0008F8-Sb for submit@debbugs.gnu.org; Wed, 28 Jun 2017 12:48:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQG8z-0008Et-RO for 27427@debbugs.gnu.org; Wed, 28 Jun 2017 12:48:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQG8r-0004zS-2H for 27427@debbugs.gnu.org; Wed, 28 Jun 2017 12:48:40 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQG8q-0004zO-Uc; Wed, 28 Jun 2017 12:48:36 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1604 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dQG8p-0007Ah-Im; Wed, 28 Jun 2017 12:48:36 -0400 In-reply-to: <59536CA6.10608@gmx.at> (message from martin rudalics on Wed, 28 Jun 2017 10:45:26 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:133993 Archived-At: > Date: Wed, 28 Jun 2017 10:45:26 +0200 > From: martin rudalics > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > But the display engine is not involved in the TTY menus, at least not > > in the usual sense. Please take a look at the second half of > > display_menu_bar, and you will see what I mean. > > Isn't display_menu_bar the code for displaying a non-X GUI menu? I > suppose you allude to the "while (!leave)" part of tty_menu_activate. > Please correct me if I'm wrong. I don't understand why this should be > relevant for popup frames, probably because I'm too silly. Sorry, you are right. I meant display_tty_menu_item. > An overlay with a 'tty-popup' property would specify a buffer position > and a newline separated text. The buffer position would implicitly > provide the upper left corner of the popup frame, the text its size. > > The display engine would notice the overlay like any other overlay. > However, the 'tty-popup' property would cause it to (1) remember the > current column of the iterator and (2) draw the first line of the > overlay right where the iterator is at this moment, possibly clipping > this line of the overlay text at the frame edge and skipping as many > characters of underlying buffer text as there are on this overlay text > line. > > On the next buffer text line the display engine would start to draw the > second line of the overlay text at the column remembered in (1), > clipping and skipping as on the first line. It would continue to > process the overlay until either its text has been used up or the bottom > of the window or the frame's root window has been reached. Alas, that is not how redisplay works. For starters, you seem to assume that it always traverses all the screen lines of a window (thus "on the next buffer line" etc.). But that is only so when a window needs a complete redisplay, and the display engine tries very hard to avoid that. Many times it only redraws some of the lines, sometimes just one line. If that line is not the first line of the popup, how will the display engine know that at some previous buffer position there is an overlay? Moreover, the same low-level display code is invoked by the move_it_* functions which simulate display without drawing anything, and those are very often invoked to traverse small portions of a buffer, typically a small number of lines. These will be in trouble as well, for the same reason. So we need a different solution, one that doesn't break due to redisplay optimizations. Dmitry, can you tell why the popup overlay is a single overlay with a single multiline string, and not a series of overlays, one each for every line shown in the popup? I assume this caused or could cause more serious problems than the current implementation, but what problems were those?