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: Tue, 27 Jun 2017 17:48:13 +0300 Message-ID: <837ezxsd02.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1498575022 26008 195.159.176.226 (27 Jun 2017 14:50:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Jun 2017 14:50:22 +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 Tue Jun 27 16:50:17 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 1dProf-0005sV-Pj for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jun 2017 16:50:09 +0200 Original-Received: from localhost ([::1]:53233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dProf-0004qj-Pl for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jun 2017 10:50:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPrnb-0004Mu-7h for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 10:49:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPrna-0007UG-7H for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 10:49:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38289) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dPrna-0007Tk-4E for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 10:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dPrnZ-0000Fv-UQ for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 10: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: Tue, 27 Jun 2017 14: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.1498574916950 (code B ref 27427); Tue, 27 Jun 2017 14:49:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 27 Jun 2017 14:48:36 +0000 Original-Received: from localhost ([127.0.0.1]:40966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPrnA-0000FF-0b for submit@debbugs.gnu.org; Tue, 27 Jun 2017 10:48:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPrn8-0000F3-8Y for 27427@debbugs.gnu.org; Tue, 27 Jun 2017 10:48:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPrmy-0005Zq-RT for 27427@debbugs.gnu.org; Tue, 27 Jun 2017 10:48:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPrmy-0005ZC-O2; Tue, 27 Jun 2017 10:48:24 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4390 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dPrmx-0000E7-R0; Tue, 27 Jun 2017 10:48:24 -0400 In-reply-to: <595203DE.1040608@gmx.at> (message from martin rudalics on Tue, 27 Jun 2017 09:06:06 +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:133950 Archived-At: > Date: Tue, 27 Jun 2017 09:06:06 +0200 > From: martin rudalics > CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org > > > If we let Emacs escape into the main loop, we cannot control when > > redisplay kicks in and what effect does it have. For example, some > > timer could display a message that could be longer than a single > > screen line, so Emacs will resize the echo area and as result > > redisplay the windows above the mode line. Since the text of the > > popup comes from a source about which the display engine knows > > absolutely nothing, redisplay will do its job assuming that the screen > > shows the contents before we overwrote it, and thus will completely > > mess up the display. Even if the code which displayed the popup gets > > control right away (which isn't guaranteed in general, since > > company-mode wants to be able to run arbitrary Lisp given user > > interaction with the popup), the user will see a momentary flash of > > messed-up display. > > I assume that the buffer position of the popup would have been specified > by company-mode before. Hence, if on a terminal the character at that > position would get displayed, the display engine would try to display > the overlay for the popup there instead. On the right and below of that > position if it fits, "anywhere there" otherwise, possibly truncating it > to keep the echo area free as you did for menus. And that overlay would > stick at that buffer position until company-mode removes it. > > So resizing the echo area would, in the worst case, not display the > popup because its buffer position would be temporarily off screen. But > I can't imagine any mess up here. I think we are miscommunicating. I was describing what would happen if we try to use the same method as used for TTY menus. There are no overlays there, the glyphs are concocted out of thin air by C code and put into the glyph matrices, overwriting what the display engine thinks should be there. By contrast, you are talking about using an overlay, which is what company-mode is using already, and which is the source of the trouble Dmitry would like to avoid. The basic problem here is that the company-mode popup is multiline, and Emacs cannot display rectangular regions, only lines. So company-mode inserts newlines into the overlay string, and the result is that the popup covers parts of the display which company-mode doesn't want to conceal. So it needs to copy those parts to the overlay string, to make the impression they weren't covered by the overlay. It also needs to make all kinds of layout calculations and decisions. All that in order to make an impression of displaying a rectangular region at certain screen coordinates, something that we ideally should have provided in the display engine. > > I don't see how the echo area can fit the job, since the space there > > is very small and there's no way to let the user select an alternative > > using menu-like interaction. > > The echo area can be resized and can emulate any menu-like interaction. Yes, but not conveniently. And if we are going to emulate, why use the echo area at all? why not pop up a buffer, like Help mode does?