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: Tue, 23 Jun 2015 19:39:55 +0300 Message-ID: <83vbeefkf8.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435077753 29882 80.91.229.3 (23 Jun 2015 16:42:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jun 2015 16:42:33 +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 Tue Jun 23 18:42:25 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 1Z7RHE-0003g4-7v for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 18:42:24 +0200 Original-Received: from localhost ([::1]:46381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RHD-0001Iq-NQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 12:42:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RG0-0007hx-L5 for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 12:41:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7RFv-0006tL-SI for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 12:41:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7RFv-0006t3-Gn for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 12:41:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z7RFu-0005sC-VY for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 12:41:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jun 2015 16:41: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.143507762122520 (code B ref 20847); Tue, 23 Jun 2015 16:41:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 23 Jun 2015 16:40:21 +0000 Original-Received: from localhost ([127.0.0.1]:55523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7RFD-0005r9-Kk for submit@debbugs.gnu.org; Tue, 23 Jun 2015 12:40:20 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:46982) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7RF9-0005qq-5F for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 12:40:17 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NQE00800OJ4F500@mtaout24.012.net.il> for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 19:31:35 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQE002PVOKMJT50@mtaout24.012.net.il>; Tue, 23 Jun 2015 19:31:35 +0300 (IDT) In-reply-to: <558878BE.3000709@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:104272 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Tue, 23 Jun 2015 00:06:06 +0300 > > On 06/22/2015 07:26 PM, Eli Zaretskii wrote: > > >> This doesn't seem to have any effect, though. Adding > >> > >> (when (eq ?\n (char-after (overlay-start ov))) > >> (let ((inhibit-modification-hooks t)) > >> (put-text-property (overlay-start ov) (1+ (overlay-start ov)) > >> 'cursor t))) > >> > >> to the end of company-pseudo-tooltip-unhide creates no change in the > >> behavior. > > > > That's because I have yet to write the code to support that ;-) > > I'm not sure I like that idea. If I have to write a workaround (this > definitely feels like it), I'd rather write a workaround that will work > in the current Emacs releases too. (If I manage to, of course). Would it be possible in this specific case to start the overlay from the next line, i.e. leave the newline alone? I think if you do that, things ought to work without any changes. Since the "tooltip" pops up below this line, it seems to me that the newline which begins the overlay now is not needed, is it? > And supporting `cursor' on buffer text newline but not on overlay > display string newline feels like adding a yet-another edge case. It's indeed a kludge. I just didn't have any other ideas. > Going back to your earlier message, I'm actually not sure I agree with this: > > > Any scenario where a screen line ends in a newline that comes from an > > overlay string [performs better under the current behavior]. Try > > several such scenarios, and then tell me whether > > the place we display the cursor looks better than the alternative. > > The current example shows that it's better to display the cursor on the > margin, rather than after the overlay. What are the examples where this > is not true? All the others ;-) > Are those cases where the said newline is not at the beginning of > the overlay? No, I think what makes this case special is the fact that (the visible part of) the overlay begins on the line below the one where the user types. So from the user POV, the current line is still occupied only by buffer text, and so users will expect the cursor to be displayed as if there were no overlay at all. By contrast, the "usual" case with overlays that span multiple lines is that the situation with positioning the cursor arises when some of the overlay string is visible on the current line, and then the user expectation is to see the cursor after the string. That's what the code which handles this situation tries to make happen. > Even if cursor would look weird in some case, at least point is not > forcibly moved to a different position. We are in agreement regarding the best place of showing the cursor in this case. The only problem is how to do that.