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 21:24:39 +0300 Message-ID: <83d20oj4wo.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1434911182 4704 80.91.229.3 (21 Jun 2015 18:26:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jun 2015 18:26:22 +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 20:26:11 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 1Z6jwY-0001xG-HW for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 20:26:10 +0200 Original-Received: from localhost ([::1]:37018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jwX-0000zk-NA for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 14:26:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jwU-0000zU-LN for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 14:26:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6jwR-0003np-DF for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 14:26:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jwR-0003nf-9L for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 14:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6jwQ-0006fE-Qz for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 14:26: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 18:26: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.143491110525551 (code B ref 20847); Sun, 21 Jun 2015 18:26:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 21 Jun 2015 18:25:05 +0000 Original-Received: from localhost ([127.0.0.1]:53571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6jvT-0006ds-4L for submit@debbugs.gnu.org; Sun, 21 Jun 2015 14:25:04 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:60533) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6jvP-0006dP-GJ for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 14:25:00 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NQB004004AG4I00@mtaout27.012.net.il> for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 21:20:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQB00LQ74AJ2O70@mtaout27.012.net.il>; Sun, 21 Jun 2015 21:20:43 +0300 (IDT) In-reply-to: <5586FD0F.8090300@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:104185 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Sun, 21 Jun 2015 21:06:07 +0300 > > On 06/21/2015 07:43 PM, Eli Zaretskii wrote: > > > 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. > > Hmm, yeah, after sounds better that before. But we do display point in > the margin on step 6. So it must be possible. I'm quite sure the code which is responsible simply doesn't check. > > 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. > > Not really. I only know that *I* can't move cursor by any other means. > > I also vaguely recall someone (yourself?) stating that this limitation > could be lifted without too much work. It should be possible, yes. I was describing how the code works now. > >> 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? > > True. > > > 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. > > Augh. > > Like mentioned in the previous message, I don't see a good, > non-user-confusing place for it on the same line. The beginning of the > next line would've worked reasonably well, though. Then what you had in mind should do the trick, I think. > I'd also accept the cursor not being displayed at all. That's tricky. We only do that due to hscroll, I think. > > 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. > > I was kinda hoping that "overlay with display string starting with > newline" was the only issue. That's not an issue at all. What we need is some way of telling the display engine that this is where we want the cursor, so it could include that clue in its logic. Hmm... would it be possible to put a 'cursor' property on the newline in the buffer that follows the "hel" text? That might be all that's needed to DTRT. > >> - 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. > > Couldn't the same optimization have a reason to be enabled in both > cases? It might be worth investigating, at least. I will see what I can do. > Consistent behavior would also be good; so that the users don't have to > try too hard to catch problematic cases like this one. I think we should try keeping point at the locus of insertion/deletion.