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: Sat, 20 Jun 2015 14:51:18 +0300 Message-ID: <83wpyyiond.fsf@gnu.org> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1434801141 14315 80.91.229.3 (20 Jun 2015 11:52:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Jun 2015 11:52:21 +0000 (UTC) Cc: 20847@debbugs.gnu.org To: dgutov@yandex.ru Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 20 13:52:10 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 1Z6HJh-0006Wy-4x for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Jun 2015 13:52:09 +0200 Original-Received: from localhost ([::1]:33090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6HJg-0002V0-BF for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Jun 2015 07:52:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6HJd-0002Um-GJ for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2015 07:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6HJa-0004AW-9r for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2015 07:52:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6HJa-00049u-6M for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2015 07:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6HJZ-0007Q8-PW for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2015 07:52: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: Sat, 20 Jun 2015 11:52:01 +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.143480109228486 (code B ref 20847); Sat, 20 Jun 2015 11:52:01 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 20 Jun 2015 11:51:32 +0000 Original-Received: from localhost ([127.0.0.1]:52515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6HJ5-0007PO-Lr for submit@debbugs.gnu.org; Sat, 20 Jun 2015 07:51:32 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:49720) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6HJ1-0007P9-Nk for 20847@debbugs.gnu.org; Sat, 20 Jun 2015 07:51:29 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NQ800J00QWVRT00@mtaout24.012.net.il> for 20847@debbugs.gnu.org; Sat, 20 Jun 2015 14:42:52 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQ800JSBR7GCR10@mtaout24.012.net.il>; Sat, 20 Jun 2015 14:42:52 +0300 (IDT) In-reply-to: <83mvzvjz3w.fsf@gnu.org> 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:104149 Archived-At: > Date: Fri, 19 Jun 2015 22:07:47 +0300 > From: Eli Zaretskii > Cc: 20847@debbugs.gnu.org > > > Problem 2: > > > > 7. Type "l", see it wrapped to the next line. > > > > 8. Type backspace. See the cursor move to the second paragraph. > > > > 9. Continue backspacing. See the completion popup disappear, and the text > > being deleted in the second paragraph. > > I didn't yet finish debugging this part, but I clearly see that some > code actually _moves_ point to that place in the second paragraph, I'm > not yet sure why. For starters, if you turn off font-lock in the > buffer, this second problem doesn't happen at all. I see some weird > interaction between JIT Font Lock and the post-command-hook installed > by Company, they seem to somehow conspire to force point to move to > that place. I'll try to debug more to see why this happens. (Any > idea why Company's post-command-hook calls sit-for, thus forcing > redisplay?) I think I understand why this is happening, and I find nothing wrong with what the display engine does under these circumstances. 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. Due to this, when you type Backspace to delete "l" in "hell", and the Company post-command-hook runs and puts an overlay string on the same line that begins with a newline, the display engine decides, after redrawing the window, that it doesn't want to put the cursor there, and looks for an alternative place. The first such place is after the overlay string, so point is moved there. 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. 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. 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. I still think the overlay string is constructed incorrectly in this case, something that should be fixed in Company. The above special setting of 'cursor' could be part of that fix.