From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup Date: Sat, 24 Jun 2017 02:26:23 +0300 Message-ID: <513eca6f-998a-a937-76c4-7cf2fb0ff787@yandex.ru> 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> 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 1498260434 7514 195.159.176.226 (23 Jun 2017 23:27:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Jun 2017 23:27:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Thunderbird/54.0 Cc: alexanderm@web.de, 27427@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 24 01:27:10 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 1dOXyo-0001aU-1m for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Jun 2017 01:27:10 +0200 Original-Received: from localhost ([::1]:37614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOXyr-0001Mq-GC for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Jun 2017 19:27:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOXyl-0001Mi-AY for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 19:27:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dOXyg-0006Eh-Dg for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 19:27:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60450) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dOXyg-0006EX-91 for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 19:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dOXyf-0006qd-TG for bug-gnu-emacs@gnu.org; Fri, 23 Jun 2017 19:27:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Jun 2017 23:27: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.149826039426282 (code B ref 27427); Fri, 23 Jun 2017 23:27:01 +0000 Original-Received: (at 27427) by debbugs.gnu.org; 23 Jun 2017 23:26:34 +0000 Original-Received: from localhost ([127.0.0.1]:34894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOXyD-0006pp-RA for submit@debbugs.gnu.org; Fri, 23 Jun 2017 19:26:34 -0400 Original-Received: from mail-wr0-f169.google.com ([209.85.128.169]:34742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOXyB-0006pc-LT for 27427@debbugs.gnu.org; Fri, 23 Jun 2017 19:26:32 -0400 Original-Received: by mail-wr0-f169.google.com with SMTP id 77so84049243wrb.1 for <27427@debbugs.gnu.org>; Fri, 23 Jun 2017 16:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HnXgJdDlYIGfO/8GVH75QEecKTn0KUqk8r8nYcwhjgc=; b=WBntBaV5dUELNsPm2OEyZJFcpFliCSSvAfWvYiw2iHrtMLEE9yHMj5i6QsZ8AA1Qf8 Ye4+eGhA5C/RURmILSjU0iXLmV1V4Im4FoCokg7LkT4NQbJ6GwkqIyTbj9MVTK88/8x0 3aAbkVy8oviHpuJ5y/2a6jOBPp0R+T1F9yqf3BFi6wFjQxUjTUCjn7XZZ7jmrqhGebiy HivdkrDULf+0khjQ6JHYIZ6kKAJwPX66U/CdsLA0676kTWFIWm2tUVf4R1TDUu4TWn+P NP9XcPWq9YQXAKsqwvVqEkZlrjRWf3U5iU+3j/XQiZpAaeEZG4EadiDVLow/R/pOZrDR G49g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HnXgJdDlYIGfO/8GVH75QEecKTn0KUqk8r8nYcwhjgc=; b=BT1xkI4D4Q+2ZFC65B4uojvpIrPPiBX6RcGbcdMB2SRH/BA3XWdI54z8Swb29nFIWC PU1Tz4VR3SzlamKvB9XwxXD5q5JGICRefGp6Hai81AcucFKFs/8lqxxYMK+PrwZ/D8aU NpJkuBhe0XsDz3XgES3Q1FHQgFtDdQoWG5tnrtD0V6WvhUvWLPKcaM/K3UylJJFsfMDD KGQ/zvg7oxUoaWB4kRlKD1i9JMRss3VcJLB4WqlP5JzqbsBzmfFjm7vD8ZNep4bfSycc dPdMpC8h3LExex2yAAPgG8C7UuDRvFuxfSjOMPYnyaNL9ywHkJGisKyBApcebO/QzJuc XlpQ== X-Gm-Message-State: AKS2vOzIK+iVHnZC2h2vE2hkk1hMkS1MPQHFGg3URREBRhcK/XyW0b7p 5zyKrQEXW430ZnHs98s= X-Received: by 10.28.87.132 with SMTP id l126mr6735304wmb.95.1498260385665; Fri, 23 Jun 2017 16:26:25 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id 18sm5611853wmt.6.2017.06.23.16.26.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 16:26:24 -0700 (PDT) In-Reply-To: <83a84zul0d.fsf@gnu.org> Content-Language: en-US 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:133838 Archived-At: On 6/23/17 12:10 PM, Eli Zaretskii wrote: > Sorry, I thought that by "related to this" you alluded to the > zero-column-at-BOL assumption. I just meant that until now this code coped pretty well with what can be found in practice. There are various issues, but none of them were zero-column related. > 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. I don't remember (or see in the code) any workarounds for any of these, aside from line-prefix text property. Maybe we're missing certain problem situations, of course (examples welcome). Do most of these only appear in non-graphical mode? >> 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. In that case, I think we should try harder to make use 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. Violent agreement, isn't it? Again, it's a known problem. You're trying to work around it in a way that doesn't scale to any potential similar new features, and which breaks company-mode popup (and probably some other overlay-wrangling code as well, I'm guessing). I'm saying the users seem willing to wait for a scalable solution, and use a margin in the meantime. After all, we have two margins, and two fringes as well. >> 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. I can try to outline a possible API. Do we have an existing bug report where that discussion would be better placed? If you have a link to a previous discussion, that would be great as well. >>> 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. It sounds like a fair amount of work, so it's low on my list. Improving ruby-mode and xref seems more important. >> 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? Should be fine, if we find no better choice. As long as that property can be set via an overlay. > (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".) Visual line sounds right. >> 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. I can't get to the actual numbers, though. And isn't counting lines in Lisp considered too slow? Or why else would we have this new feature? > (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.) I did, it's in the middle of your quote. ;-) > 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. Agreed that it's the right direction (although I wouldn't say no to a popup library in the core either ;-). Would it help in non-graphical mode, though? Does it support non-maximized frames? > 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. Let's try it, if it's not hard to add. I'll report back as soon as it's available.