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: Wed, 28 Jun 2017 10:45:26 +0200 Message-ID: <59536CA6.10608@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> <595203DE.1040608@gmx.at> <837ezxsd02.fsf@gnu.org> <59527971.5000205@gmx.at> <83y3sdqtto.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: quoted-printable X-Trace: blaine.gmane.org 1498639584 25353 195.159.176.226 (28 Jun 2017 08:46:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Jun 2017 08:46:24 +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 Wed Jun 28 10:46: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 1dQ8c1-0005ul-BR for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 10:46:13 +0200 Original-Received: from localhost ([::1]:59749 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQ8c3-0007bc-GE for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Jun 2017 04:46:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQ8bv-0007bV-Th for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 04:46:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQ8br-0002oF-0T for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 04:46:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38884) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dQ8bq-0002nv-MD for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 04:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dQ8bq-00062D-9k for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2017 04:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Jun 2017 08:46:02 +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.149863954523170 (code B ref 27427); Wed, 28 Jun 2017 08:46:02 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 28 Jun 2017 08:45:45 +0000 Original-Received: from localhost ([127.0.0.1]:41561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQ8bY-00061e-QP for submit@debbugs.gnu.org; Wed, 28 Jun 2017 04:45:45 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:51739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQ8bX-00061Q-8g for 27427@debbugs.gnu.org; Wed, 28 Jun 2017 04:45:44 -0400 Original-Received: from [192.168.1.100] ([46.125.250.47]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M55BC-1dgA5J3gUA-00zIVb; Wed, 28 Jun 2017 10:45:36 +0200 In-Reply-To: <83y3sdqtto.fsf@gnu.org> X-Provags-ID: V03:K0:hvMECmynGl1UBEO2oBf3RHxiNZ4Tr0cMxJRRvq4KNqDwPVKBt26 e2puTWNilHzQYL6Wlr1UwYXqxDDv3vYwKkJOf+8DiXA2zI8I5AxK8DUHadiAFntLlBysPXE FrlJmSkZozmpSxry1scwOzjR6fqObHnlNCtvbAESG0KwvOQ0pFocqLJcEOqZC9u6x2MegYg FBLwJ8yHB68gOxJuhc6Mg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Lqx0bIGkm9k=:mG6cTOb+1Gmvl+9r6mPgBb h7Ikwsm7qr/Rfb2q3E3CQbcuToWlzQ0dNEY4bChHFzrf94cOuYKZHhdpRr8BIqjNfKEdnBdo+ dq1DazAVcmr+uzTtwXZad4MrdiIz/nIW8UjX8M+fcdeS3n5WzSj906BcWfbvKvFFQ6GImU9Ag CQkFkH/MsYmJsXgvo5SRUdPK0P3AxtGDzOP0LlBHSwK1UqWIUJHDziM3vmpCgEIUWwUseGIzO qhvB/mO0FsK5wXsvq/zxyJ96Sc20Trw6YiHdjwcUWLT6T473SgGCGp3ajM5yb0514Q+bsKmJW JrvTkHOoa4D/zeuJChbVEt4Jhs2HuVNqI1GCQppL89dQGjMyGfaxYhweXhG6jkewtH6gRiCly Gp0H0kqY5UuvGSrI1oHn9sHjRgrwYifzIQTHrQVKif7VhVwcwP82a6VO3jZfPGlb7nXpGk/tn 5XCiDOG8IfrgOLx7qqHVTaUfGfbmpgkQLY0E+lM5/2+/lleumjZE2sp3cDbfhOEaSqcmXE6gh R2x8Yc5JoEdmE+pZtfWIFeWZd+2X05vdTHt/yEWTeqZXpTKSJ05trMnn+T63Dp4KP/gcTGyO7 AECCf4CwR3aUq1Afb6ztGNTHE8ATbHzJ2C9oZoghHJh6LAv6nfLE268ARjAqFB8McElgL1SBP Af2KpUcl4lRa5D9ZJinoRmwYDEc5Iqq71sZ23r3ImWX5IrkZtxr86Bh9Uo5Zp5vLFp8erbCsn fMAZ1r0Xinw5UJyx8CAS8Gg4gylSQyvukDistmSe6vNATozWWu309d+AmNF89MOG+HYOALzN 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:133979 Archived-At: > 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. So let me try again how I think a popup frame could be emulated on a TTY. Currently, on a TTY a popup frame is nothing else but a normal frame because all special frame parameters are inhibited. Hence, it will have the same size and position as the frame above which it is supposed to pop up, which doesn't make any sense. To specify the position and contents of a popup frame on a TTY I see two ways: Either in the buffer text via a normal Emacs overlay with a say 'tty-popup' property or via a separate list say =E2=80=98tty-popup-frames= =E2=80=99. The following sketch is based on the former. 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. Any redisplay would now redraw the popup frame in the same way, possibly at a different position or with different size. The overlay would probably need a 'window' property to allow showing the same buffer position in several windows and some convention would be needed for how to draw overlapping popup frames. The overlay would be removed from its buffer by the same function that makes the GUI popup frame invisible or kills it. Removing the overlay would cause a redraw just like removing a GUI popup frame would cause an expose event and a subsequent redraw. I don't think that the extra check for the column stored in (1) would be overly expensive. If a separate =E2=80=98tty-popup-frames=E2=80=99 list = were used (each entry containing a buffer position and a newline separated text), then an approach where the desired glyph matrix is overwritten as with TTY menus would be used. This would remove the need for (1) at the expense of calculating the desired position of the popup in the glyph matrix from the buffer position and the need to overwrite the relevant portions of the desired glyph matrix. martin