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: Fri, 23 Jun 2017 12:10:58 +0300 Message-ID: <83a84zul0d.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1498209131 16864 195.159.176.226 (23 Jun 2017 09:12:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Jun 2017 09:12:11 +0000 (UTC) Cc: alexanderm@web.de, 27427@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 23 11:12:06 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 1dOKdK-00047E-IZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jun 2017 11:12:06 +0200 Original-Received: from localhost ([::1]:34297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOKdP-0004VA-Oi for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jun 2017 05:12:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOKdJ-0004V3-6I for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 05:12:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dOKdF-0003be-TT for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 05:12:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59417) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dOKdF-0003ba-Q1 for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 05:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dOKdF-0001kX-Ke for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 05:12: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: Fri, 23 Jun 2017 09:12: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.14982090766666 (code B ref 27427); Fri, 23 Jun 2017 09:12:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 23 Jun 2017 09:11:16 +0000 Original-Received: from localhost ([127.0.0.1]:33861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOKcV-0001jS-QZ for submit@debbugs.gnu.org; Fri, 23 Jun 2017 05:11:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOKcT-0001jC-BV for 27427@debbugs.gnu.org; Fri, 23 Jun 2017 05:11:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dOKcK-0003OU-SE for 27427@debbugs.gnu.org; Fri, 23 Jun 2017 05:11:08 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOKcK-0003OO-OR; Fri, 23 Jun 2017 05:11:04 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4572 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dOKcJ-0001jf-R0; Fri, 23 Jun 2017 05:11:04 -0400 In-reply-to: <49b431fd-aaa4-e7ca-06fc-7146a0a5692c@yandex.ru> (message from Dmitry Gutov on Fri, 23 Jun 2017 02:17:24 +0300) 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:133829 Archived-At: > Cc: alexanderm@web.de, 27427@debbugs.gnu.org > From: Dmitry Gutov > Date: Fri, 23 Jun 2017 02:17:24 +0300 > > On 6/22/17 5:55 PM, Eli Zaretskii wrote: > > >> Yep! And there are zero outstanding bug reports related to this. > > > > Well, except this one ;-) > > But it's not about line-prefix, it's about a new feature in Emacs that > was just introduced in a way that's different from those that came before. Sorry, I thought that by "related to this" you alluded to the zero-column-at-BOL assumption. > > Keeping the numbers out of the margins was my explicit design goal, > > because some packages want the margins, and we don't have a good > > solution for "sharing" margins. > > It's not without problems, though, as it introduces a new, different > type of margin, doesn't it? Not really. The display engine was always inserting stuff at the beginning of a visual line. Some features that use this include line-prefix and wrap-prefix, the left truncation glyphs, and overlay-arrow. It's just that AFAIU company-mode has coded workarounds for each one of them, and now there's one more feature to deal with. > Why not put it outside of the window bounds next to the "actual" > margins? That's one option. That option requires a thorough redesign of the canvas geometry used by the display engine: currently there's no area for it to put glyphs except the 3 existing ones -- the two margins and the text area. > > So from my POV putting the numbers in > > the margins would be a step backward. It will probably also create > > major havoc for the few packages that do display in the margins, > > Not any more havoc than linum or nlinum which many people install and > use, and are apparently fine with them taking up one of the margins. As long as only one mode uses the margins, no problems indeed. Once there are two or more, they need to work around one another, and that doesn't work very well, sometimes not at all. > But of course, it would be ideal if you could also introduce a facility > that would allow sharing of margins (and hopefully also fringes) between > different modes. Alas, we don't have any consensus for how should this be done. > > Not sure what you mean by "chromeless" here, but if I understand you > > correctly, Martin's work is already on master. > > I think so, yes. I'd urge you to see if company-mode can switch to using these facilities, as working against the display engine works only up to a point, and doubtless causes many maintenance headaches. > >> 1. The first visual line containing the popup has the line number at its > >> beginning. And as such, the popup line is shifted to the right. > > > > That's the "BOL at non-zero column" issue, right? > > Yes, but also the lack of ability to disable the line numbering on a > line-by-line basis (which could be one solution for this problem). If providing such a facility would solve the problem, it should be easy to code. E.g., we could have a display-line-numbers-disable property which a Lisp program could put on the first visible character of a visual line, and a non-nil value of that property would signal to the display engine not to produce the line-number glyphs for that visual line. Would that be okay? (Note that line-number display produces glyphs even for lines for which no number should be displayed, such as continuation lines and empty screen lines beyond EOB, so company-mode would need to decide whether it needs to disable those as well. Which is why I wrote "the first visible character of a visual line" above, emphasis on "visual".) > Imagine of the line numbers were displayed using line-prefix (I'm not > really suggesting that, but...). Then the popup could pick them up and > include in the overlay's `display' property text. The user wouldn't see > any difference. You can do similar things with line numbers: Lisp code can count lines as well as C code, and the fact that the line numbers are being displayed is easily detected from Lisp. > Suppose X is non-zero because of line numbering. Then adding an offset > of X to the position of the first popup line should fix it. > > What if X is non-zero because of line-prefix, though? If it's because of > line-prefix variable, okay, we don't support it. > > What if X is non-zero because of the line-prefix text property? We'd get > an "array out of bounds" error somewhere, because the first popup line > is currently positioned correctly. > > So when should we add an X offset to the first popup line's position? > > Suppose X is non-nil because of line numbering and the line-prefix text > property both? Org uses the line-prefix text property in certain > configurations, so it's a real possibility. > > One idea would be to first create an overlay on the first visual line > which overrides the line-prefix property to zero, *then* measure > > (car (posn-col-row (posn-at-point (beginning-of-visual-line)))) > > , then delete the said overlay and proceed. Doesn't that sound like a > mess already? (And you didn't yet consider the possibility of _both_ line numbers and line-prefix. Yes, that should be possible, and I intended that to be supported.) Anyway, the mess should be expected in any feature which attempts to change the display in significant ways, like company-mode does. Experience shows that this only works up to a point. Which is why The Right Way to implement such features is to introduce infrastructure (on the C level) which will allow the display engine to do the layout job as those features need. Native display of line numbers is one step in that direction, from my POV. I hope that Martin's work on child frames will allow company-mode to go in a similar direction as well. However, this bug report is about letting the current implementation of company-mode live in peace with native display of line numbers. So if you tell me that the above-mentioned property will allow such a coexistence, I will code it. Thanks.