From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location Date: Wed, 24 Jun 2015 19:18:54 +0300 Message-ID: <83pp4ldqq9.fsf@gnu.org> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> <83wpyyiond.fsf@gnu.org> <5586C2A8.1020904@yandex.ru> <83h9q1hv0t.fsf@gnu.org> <5586FD0F.8090300@yandex.ru> <83d20oj4wo.fsf@gnu.org> <5587185A.306@yandex.ru> <83616gihqd.fsf@gnu.org> <55881053.3080604@yandex.ru> <83oak7hfq6.fsf@gnu.org> <558878BE.3000709@yandex.ru> <83vbeefkf8.fsf@gnu.org> <5589A92A.5080709@yandex.ru> <83k2uufdkg.fsf@gnu.org> <5589CC8D.80608@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435162829 19844 80.91.229.3 (24 Jun 2015 16:20:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2015 16:20:29 +0000 (UTC) Cc: 20847@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 24 18:20:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z7nPN-0008Jx-D3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2015 18:20:17 +0200 Original-Received: from localhost ([::1]:51788 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7nPM-0007EI-Qa for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2015 12:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7nPI-0007E3-RV for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2015 12:20:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7nPB-0000t2-1j for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2015 12:20:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55151) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7nPA-0000rO-Vj for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2015 12:20:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z7nP9-0005N0-Rp for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2015 12:20:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jun 2015 16:20:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20847 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20847-submit@debbugs.gnu.org id=B20847.143516275620580 (code B ref 20847); Wed, 24 Jun 2015 16:20:03 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 24 Jun 2015 16:19:16 +0000 Original-Received: from localhost ([127.0.0.1]:56597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7nOM-0005Lq-A4 for submit@debbugs.gnu.org; Wed, 24 Jun 2015 12:19:16 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:47246) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7nOI-0005La-Oh for 20847@debbugs.gnu.org; Wed, 24 Jun 2015 12:19:12 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NQG00E00IJNT500@a-mtaout21.012.net.il> for 20847@debbugs.gnu.org; Wed, 24 Jun 2015 19:19:04 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQG00EIHINRP450@a-mtaout21.012.net.il>; Wed, 24 Jun 2015 19:19:04 +0300 (IDT) In-reply-to: <5589CC8D.80608@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:104308 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Wed, 24 Jun 2015 00:15:57 +0300 > > On 06/23/2015 10:07 PM, Eli Zaretskii wrote: > > > "Now" as in "what Company does now". > > It very much uses that newline "now". Yes, and I was asking whether in this specific case it could refrain from doing that. (And yes, I understand that doing so would be additional complexity for you.) > > emacs -Q > > M-: (overlay-put (make-overlay 65 66) 'before-string "how\ndo\nyou\ndo?") RET > > But there's nothing special about newlines here. The display engine > probably never "tried" to display the cursor at any of those that are > inside the display string. Yes, it did. When the display engine needs to decide where to put the cursor, it examines all the screen lines whose buffer positions are around point. So in this case, it did examine all those lines that came from an overlay string, and rejected them all. > >> The fact that you'd *try to* display the cursor at the newline > >> belonging to an overlay display string indicates that the overlay > >> must start at that position, doesn't it? Or end. > > > > Sorry, I don't follow: what do you mean by "you'd try"? > > Consider for displaying the cursor at? > > Allow me to quote yourself: "In a nutshell, when a screen line ends in a > newline that comes from an overlay string, we don't want to display the > cursor on that line." > > For that heuristic to apply, I'd say first you have to "try" to display > it at that position. We do, see above. We actually examine all those lines one by one. > >> If it starts earlier, then the cursor might be displayed before or after > > > > We always display it after, when point is at buffer position that has > > an overlay string property. > > So maybe I misunderstood, and there's no heuristic about newline at the > end of visual line coming from an overlay. No, you didn't misunderstand. There is such a heuristic. > And that other circumstances conspire to make it seem that way, > namely: > > - Cursor is always displayed after an overlay when it's "inside" it. > - We somehow always consider point to be "inside" overlay when it's at > the window edge, and an overlay begins there too. That's correct, but the heuristic applies to the line where the overlay string ends, when it ends with a newline that comes from the overlay string. When this happens, we could place the cursor either at the end of the line with that newline, or at the beginning of the next line. We prefer the latter. > Maybe the latter could still be changed. I tried to do that, but unfortunately, when the display engine gets to the point where it needs to place the cursor, it lacks information for treating this situation specially. That's because the information about the overlay is long gone, and the newline didn't leave any glyphs on the screen. So it's impossible to discern between this situation and any other where we have a a line ending in a newline that comes from an overlay string, without once again searching for the overlays in the buffer, soring them, finding the ones that should have been displayed, etc. > >> If it ends later, why would we even try to display the cursor at > >> that newline in the first place? > > > > Because its corresponding buffer position matches point. That's how > > cursor positioning works in Emacs: it always starts by looking for the > > glyph on the screen that corresponds to the buffer position where > > point is. If such a glyph is not found, for one of the many reasons > > (invisible text, overlay or display string, hscroll, you name it), > > then the fun begins: we try very hard to find some alternative > > position that fits. > > Then the overlay must begin at the edge of the window, and all the cases > where your quote (above) applies look like this case. Yes. And that's exactly the problem: we would like to treat this case differently, but don't have the necessary information to do so. What I need to do so is (1) the starting and ending point of the overlay which begot the string, and (2) the fact that the string begins with a newline, or some handle for the string itself. None of that is available at the point where we decide whether this line is "appropriate" for the cursor. > >> But then, maybe I don't really understand what it does. > > > > I can tell you which parts of code to read, if you want. > > If you think that's wise. It's not up to me, it's up to you. If you want to understand the gory details without myself standing in between (and maybe describing some things inaccurately or not clearly enough), then I will gladly tell you where to look. I'm also okay with describing it for you as best I can, like I did until now. It's your call.