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: Mon, 26 Jun 2017 10:21:15 +0200 Message-ID: <5950C3FB.1060200@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> <594FEE69.5010106@gmx.at> <83y3sfsym4.fsf@gnu.org> <83wp7zsxxn.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 1498465343 27581 195.159.176.226 (26 Jun 2017 08:22:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2017 08:22:23 +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 Mon Jun 26 10:22:11 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 1dPPHd-0006Yb-Mh for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jun 2017 10:22:10 +0200 Original-Received: from localhost ([::1]:45253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPPHi-0004VI-Lg for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jun 2017 04:22:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPPHb-0004Ux-6u for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 04:22:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPPHW-0007TJ-8w for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 04:22:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dPPHW-0007TF-5f for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 04:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dPPHW-0003xz-00 for bug-gnu-emacs@gnu.org; Mon, 26 Jun 2017 04:22: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: Mon, 26 Jun 2017 08:22: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.149846529015197 (code B ref 27427); Mon, 26 Jun 2017 08:22:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 26 Jun 2017 08:21:30 +0000 Original-Received: from localhost ([127.0.0.1]:37950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPPH0-0003x2-9a for submit@debbugs.gnu.org; Mon, 26 Jun 2017 04:21:30 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:54313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPPGy-0003wn-2w for 27427@debbugs.gnu.org; Mon, 26 Jun 2017 04:21:28 -0400 Original-Received: from [192.168.1.102] ([46.125.249.54]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M5csW-1decsU0yKG-00xeLp; Mon, 26 Jun 2017 10:21:22 +0200 In-Reply-To: <83wp7zsxxn.fsf@gnu.org> X-Provags-ID: V03:K0:PwtzWVxiHM2S5e1MARHXlvVVZsXMlFQff7UMEvxCXLDa+VkEDRU e5G1rXcJFYFcD4MJmaVZQVVF61nR9JATNhfllnp4HvfZYaRquQPCXiSILIYBIM313voeBk9 NJKMXlO7nHXZCc7jKbvBRGvGzEX2XhBJ2v+Zl8nVVXFN5rb9UbQpGE0fqLB3ymLK28wuWtz hnyBLuPIwGGiuNKpAO/xw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OSSirgKjKhQ=:d37QAV0YjQn9yprQZS7Gny mNb4JPOH7RvZqikUC0xYoG2vWB5i3x+dL6OkSFeEOI7OVXTDHgmLFXlccziy9X7UiTsOj2OsO R7a/GFy4ZRrfiWkCmtywqVV3/djUN8wVex5KqbZ8VY76o9KTBtnbEZXNCMg8osHcQif4fd7HX suLQLBbUGK5Nz061pJ11F3E7sZT9cS7771uP6MVOwEim6a91EGLNuj8p/lAW7zWs2GNHz5l9U GpailFKd31j1iXMQdhRGR4gy6HoNvEIimVUtleuxiZ1dkhaIiwKedcGvs5XMtDvOwwGLurR/S ixCvbtEqC4g21Ybx9fUElrQ9O4QFRmv/70GA/a+3geUIr1vZE+onV/VPJH4+5BRG3X8BhhfCk Hsdi6fmjEIedioowQksg9PFpD9crn4JSE+vMYmZEbPPKGP8kr77/Qn4FiKr2L21E/bgBNoggg R5COIy3o9Ee6T52MRIrjzIO71t3ctAJbJP9eszuYGHjsLQq85rrE1fy1sgdW1bJh93HFTTu77 115qF6g03+MZtsBTLAgpofezE8Bj/2kmYysAabuF13+NwETQhOTio5ilmzutg5uiEUJKooevy Jk6GVh+OcjU+LPQ7ju7iOHM6aJeh4+rKhOEfZ8ug1WM1fXZYmNkxCJTeWxLIvE7VrshbMdkth V8/N8bbOGDsACJ/VaRi1TwvGuYUjOfUQOA1anX49NwYv67zFsiWCSAAglZ3u1bssaI47M4UIz ub9xVBFrVkZYTEBtasv13sbrnpSXjO9dZCE2qg86S4liOuT6X06koISfWpXCBQ1OUpTnoVN2 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:133915 Archived-At: > Btw, it strikes me that if we want something like that, it should be > much easier to provide side-by-side windows that scroll together or > according to some predefined relation. This at least doesn't need to > redesign the basic display geometry of a window, only to change the > order in which we traverse the window tree -- instead of the current > depth-first order we'd need some more complicated traversal, and > perhaps also some redisplay considerations that look at more than one > window at a time. Then just removing the scroll bars from all but one= > of these "lockstep" windows will get you what you want at a much > smaller effort. This is precisely what I had in mind and why I pleaded for a uniform handling of windows elsewhere. The question is whether and how to treat margins, scroll bars and fringes as first class citizens in this regard. Our scroll bars are already partly windows partly frames. Hence considering them a shared resource like the tool or menu bar windows/frames should be straightforward. Margins, fringes and line numbers are subordinates but I would upgrade them so the display engine is mostly disconnected from the layout problem. Now I think we agree that two or more side-by-side windows emulating =E2=80=98follow-mode=E2=80=99 should share a single vertical scroll bar w= indow whose slider size and position would be computed from the amount of text displayed in all of these windows taken together and the position of =E2=80=98point=E2=80=99 in the most recently selected window of them. I think we could also have these windows share a common fringe and a line number window. I'm less sure about the margins. I think a vertical divider should be provided separately for each window so the user can resize them separately with the mouse. And a horizontal scroll bar, if wanted, should be provided separately for each of the windows. There's probably no rule for sharing mode and header lines: A common mode line seems obviously preferable for =E2=80=98follow-mode=E2=80=99, a= ruler in the header line can be hardly shared. An obvious problem ensuing from such an approach is, for example, that the display engine may decide that the size of the line number window must increase because one of the windows now has to display a larger maximum line number or because =E2=80=98point=E2=80=99 has moved from a w= indow with a lower =E2=80=98point=E2=80=99 to a window with a higher one. This will t= rigger a check whether the remaining windows are still large enough and maybe how to enlarge them. So what is currently a local decision entirely embedded in your line numbers code would become a more global decision of window management. martin