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: Sun, 21 Jun 2015 19:43:30 +0300 Message-ID: <83h9q1hv0t.fsf@gnu.org> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> <83wpyyiond.fsf@gnu.org> <5586C2A8.1020904@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1434905066 12503 80.91.229.3 (21 Jun 2015 16:44:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jun 2015 16:44:26 +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 Sun Jun 21 18:44:15 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 1Z6iLt-00037P-P8 for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 18:44:14 +0200 Original-Received: from localhost ([::1]:36784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6iLs-0005zo-Qt for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 12:44:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6iLl-0005y2-VX for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 12:44:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6iLi-0000HG-Ml for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 12:44:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6iLi-0000HC-HO for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 12:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6iLi-0002oT-8E for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 12:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Jun 2015 16:44:02 +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.143490503310792 (code B ref 20847); Sun, 21 Jun 2015 16:44:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 21 Jun 2015 16:43:53 +0000 Original-Received: from localhost ([127.0.0.1]:53496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6iLY-0002nz-9r for submit@debbugs.gnu.org; Sun, 21 Jun 2015 12:43:52 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45519) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6iLV-0002nl-K5 for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 12:43:50 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NQA00200ZIA5S00@a-mtaout20.012.net.il> for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 19:43:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQA002Y2ZSU1960@a-mtaout20.012.net.il>; Sun, 21 Jun 2015 19:43:43 +0300 (IDT) In-reply-to: <5586C2A8.1020904@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:104179 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Sun, 21 Jun 2015 16:56:56 +0300 > > On 06/20/2015 02:51 PM, Eli Zaretskii wrote: > > > 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. The > > reasons are heuristic, but they give good results, and we used this > > heuristic for a very long time, so changing it now is out of question. > > Do you have a scenario in mind that performs better under the current > behavior? Any scenario where a screen line ends in a newline that comes from an overlay string. Try several such scenarios, and then tell me whether the place we display the cursor looks better than the alternative. > I can understand the scenario until now, but why move point? > > Displaying cursor in a different place is relatively fine, but moving > the point is destructive. Emacs cannot move cursor except by moving point, I'm sure you know that. The only exception is when we show the cursor on a display or overlay string, guided by the 'cursor' property. There are no other exceptions. > > The font-lock part of this riddle is that when font-lock-mode is > > active in the buffer, making any changes to buffer text cause JIT Lock > > to spring to action, which doesn't really do anything, but disables a > > certain redisplay optimization, which bypasses the above test. > > Sounds messy. You can say that again. > > My suggestion would be to use the 'cursor' property on the overlay > > string in some place where it could be picked up by the display engine > > (i.e. not on a newline), to countermand this problem. > > See the bottom of `company--replacement-string'. If `cursor' is applied > unconditionally, and if I change the arguments 0 and 1 to 1 and 2, on > step 6 the cursor is displayed at the beginning of the next line (so we > know the change has effect), but the second problem (after step 9) is > still present. AFAICT, this will put the 'cursor' property on a character that is after the leading newline of the overlay string, yes? If so, that's not going to work: you need th 'cursor' property on some glyph that is displayed on the same line where the newline is. That is, you need to make at least one character of "hel" part of the overlay string, and put the 'cursor' property on it, making its value large enough to "cover" the position of the newline. > > E.g., perhaps > > begin the overlay string a few characters earlier, so that it replaces > > part of buffer text in "hel", and have the 'cursor' property on that > > part of the string. > > That's doable, even if I don't like the extra complexity. Are you sure > about this? I didn't have time to actually try that, I just looked at the code. So it might not work as things are, but if so, I'm quite sure I can fix that. As long as some glyph that came from the overlay string is visible on the same line, and the corresponding string character has a 'cursor' property on it, the display engine has enough information to decide that the cursor can be displayed there (on the fringe). > Do you also have explanations for the following? > > - The bug only manifests after the step 9 (backspacing), whereas the > whole explanation seems to apply to the step 6 as well. Yet, point stays > in place there. Like I said, I didn't investigate that. I think some redisplay optimization is responsible. If it's important to have the same (mis)behavior in both cases, I can look into that. > - With bidi-display-reordering set to nil, there's no bug. Because the unidirectional display could assume that buffer positions increase monotonically with the screen's vertical coordinate, and so once it saw a single screen line whose first and last characters have buffer positions on both sides of point, it could decide to put the cursor on that line right there and then; it didn't need to test other conditions or consider following screen lines. So this situation worked "by sheer luck". The bidirectional display doesn't have that luxury, so it needs additional support information, and that information is simply absent in this case.