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: Mon, 26 Jun 2017 18:05:17 +0300 Message-ID: <83mv8ussb6.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1498489575 8198 195.159.176.226 (26 Jun 2017 15:06:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2017 15:06:15 +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 Mon Jun 26 17:06:07 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 1dPVaZ-0001i7-HT for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jun 2017 17:06:07 +0200 Original-Received: from localhost ([::1]:47108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPVae-0003SP-TO for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jun 2017 11:06:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPVaY-0003S7-J2 for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 11:06:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPVaT-0008Eb-WE for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 11:06:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dPVaT-0008EU-Se for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 11:06:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dPVaT-0000MU-LN for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 11:06: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: Mon, 26 Jun 2017 15:06: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.14984895431365 (code B ref 27427); Mon, 26 Jun 2017 15:06:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 26 Jun 2017 15:05:43 +0000 Original-Received: from localhost ([127.0.0.1]:39263 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPVaA-0000Lw-NC for submit@debbugs.gnu.org; Mon, 26 Jun 2017 11:05:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPVa8-0000Lh-22 for 27427@debbugs.gnu.org; Mon, 26 Jun 2017 11:05:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPVZy-00085O-FK for 27427@debbugs.gnu.org; Mon, 26 Jun 2017 11:05:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPVZy-00085E-BL; Mon, 26 Jun 2017 11:05:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3489 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dPVZx-00038v-Ek; Mon, 26 Jun 2017 11:05:29 -0400 In-reply-to: <5950C342.7010908@gmx.at> (message from martin rudalics on Mon, 26 Jun 2017 10:18:10 +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:133926 Archived-At: > Date: Mon, 26 Jun 2017 10:18:10 +0200 > From: martin rudalics > CC: alexanderm@web.de, 27427@debbugs.gnu.org > > > Yes. We simply overwrite the glyph matrices with the menu contents, > > and then force a screen update. > > We would have to do the same for popups. Doing that behind the back of the display engine is problematic, see below. > > But this cannot work for features that want Emacs to return to the > > main loop, because anything that triggers any kind of redisplay will > > restore portions of the display from buffer text and mess up the menu. > > And for popups it would just have to overwrite the glyph matrix again. > Or what am I missing? 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. > Yet I doubt that such popups would be desirable on terminal frames. For > my taste, they would appear far too obtrusive and distracting. I think > any such popup should be treated like a tooltip and get displayed in the > echo area. 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.