From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics 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 09:06:06 +0200 Message-ID: <595203DE.1040608@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1498547236 17395 195.159.176.226 (27 Jun 2017 07:07:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Jun 2017 07:07:16 +0000 (UTC) Cc: alexanderm@web.de, 27427@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 27 09:07:12 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 1dPkad-0004Cp-DG for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jun 2017 09:07:11 +0200 Original-Received: from localhost ([::1]:50978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPkai-00083m-D6 for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jun 2017 03:07:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPkaX-00082a-Fo for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 03:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPkaU-0000sR-Ax for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 03:07:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37232) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dPkaU-0000sH-6s for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 03:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dPkaT-0001iT-Td for bug-gnu-emacs@gnu.org; Tue, 27 Jun 2017 03:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Jun 2017 07:07: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.14985471836526 (code B ref 27427); Tue, 27 Jun 2017 07:07:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 27 Jun 2017 07:06:23 +0000 Original-Received: from localhost ([127.0.0.1]:39906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPkZq-0001hC-PA for submit@debbugs.gnu.org; Tue, 27 Jun 2017 03:06:22 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:63034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPkZp-0001gv-EB for 27427@debbugs.gnu.org; Tue, 27 Jun 2017 03:06:22 -0400 Original-Received: from [192.168.1.100] ([213.162.68.23]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MRGvT-1dK5W63HTz-00UcN5; Tue, 27 Jun 2017 09:06:13 +0200 In-Reply-To: <83mv8ussb6.fsf@gnu.org> X-Provags-ID: V03:K0:kxmZOSZ1nYO+Up0Fo07SXeCQXo+t6iobloKe2zmAtmCdeHP/yVg tLxZx0om7iFRq1rTaSitY7N1184GD52EMRCuJCbUJGFmVRn4Um+3J4iOZRHE7TgGikR8e8R AxUF4nx10nmbO1/QlKTYAgDERuHgTImbi37qbunS9zDDWabzgjuMjL3WqE1OTbJ5guRlD6Y N6S1m22LiIAkghqg6e1IA== X-UI-Out-Filterresults: notjunk:1;V01:K0:EIv4XXhBnaA=:ZJEc3bEsxQxu9JTipg481g u+8yF36sSWNyDrNmF2jmv0s67NIDsrHZ1If5L2uqIo7sKA2czUBnavEaxyVmoXQtwMYTpULZJ 96PtUJihjodIH2eQaVe6wHkLVuVaMtHdGMoPmxsjw5pfRzRn0Ng+xC/9Ui4n7ahl3Est4yqx6 I+dwZP46MYE4slcL5aQvzJm6JWf1H/fxfDkUccKm3VWknCtehY1CHionvcD1sstLru1Dbri6T 7Rl9sYriHuL8oAlWAb9b5e7OKUQ+6p+s3WovrVJv92oDhYalJ709nHlOK6ZCIsMgrczn0ZwjM HVPtgMRhLEzBcod/R0tqrULqEPDUoEiw8T1It8B2Zgd1dTABTjb3rUjV52qQvNV6pyp+RFFpd iP/Ybqz/epGZaEN8IOA/H5nVrtRVgHNsCSlCp0sOTU/Rj4fw/Ax+De7KcQXAWI0jvyfEeTbxQ poRxn+NwdAtK8InNoQwTXCXYdkgPTL91EzmmAUchzdj5YpX1YJeaq5aLAYwiXLzw264zdwp7+ 9Ypks2t12wGmtYHDqxE/Df5oZq7ELP/LShWiE/mO7fBqIOpPPyi7fEMKS9LNBH0NWro4uZE6B gMufpRhFqA3KW5Hb3da+r2BaWoRDHgtDsM4ZaKGP4Ucs3BZ47QQIHRBH3ZAbj7gNQSfNyx/K3 NFk8RW9SpwWfYzqV25aQRTXCYdhXrPqp9qY9oefY8DM+aIdQiOaz8dbxAMVN3ornxyE4FcpLf 1LB/7Z09ahGLg7uxbwo2e4myPnQyeFgJfDHVXkDrLLf9AQ/kPqYvPmQAdZqbBvQSkAKFHnon 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:133945 Archived-At: > 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 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. martin