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 22:07:59 +0300 Message-ID: <83k2uufdkg.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435086563 16781 80.91.229.3 (23 Jun 2015 19:09:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jun 2015 19:09:23 +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 21:09:13 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 1Z7TZI-0002Ze-Ao for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 21:09:12 +0200 Original-Received: from localhost ([::1]:47053 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TZH-0007Qb-OF for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 15:09:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TZE-0007QA-4S for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 15:09:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7TZ9-00021k-4n for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 15:09:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TZ9-00021d-10 for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 15:09:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z7TZ8-0002XO-AG for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 15:09: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: Tue, 23 Jun 2015 19:09: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.14350865039707 (code B ref 20847); Tue, 23 Jun 2015 19:09:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 23 Jun 2015 19:08:23 +0000 Original-Received: from localhost ([127.0.0.1]:55587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7TYU-0002WU-1z for submit@debbugs.gnu.org; Tue, 23 Jun 2015 15:08:22 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:61411) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7TYQ-0002WF-5I for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 15:08:20 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NQE00000VR9TF00@a-mtaout23.012.net.il> for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 22:08:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQE000YHVTNRA30@a-mtaout23.012.net.il>; Tue, 23 Jun 2015 22:08:11 +0300 (IDT) In-reply-to: <5589A92A.5080709@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:104276 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Tue, 23 Jun 2015 21:44:58 +0300 > > On 06/23/2015 07:39 PM, Eli Zaretskii wrote: > > > 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. > > I suppose. > > > 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? > > "now"? "Now" as in "what Company does now". > >> 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 ;-) > > A concrete example would help. emacs -Q M-: (overlay-put (make-overlay 65 66) 'before-string "how\ndo\nyou\ndo?") RET > 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"? > 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. > (if wouldn't be displayed in the middle of the overlay string, right?). Never (unless there's a character with 'cursor' property). > > 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. > > If I had to pick, I'd probably always display the cursor before such > overlays, not after. That goes against what Emacs did since we began supporting overlay strings. Among other problems, it makes strange effects when inserting characters: they appear not where the cursor is. > That seems consistent with the logic of expecting the cursor "to be > displayed as if...". Again, this case is IMO singular, in that none of the overlay string characters are visible on that line. Thus "as if...". > > 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. > > If the overlay display string ends at that newline, and point is at the > end of the overlay, then the display engine exception under the > discussion will be a no-op. What exception? Sorry, I lost track: we are discussing many different things simultaneously. > 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. > >> 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. > > Removing that exception might do the trick. It will bring other problems. > But then, maybe I don't really understand what it does. I can tell you which parts of code to read, if you want.