From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location Date: Wed, 24 Jun 2015 00:15:57 +0300 Message-ID: <5589CC8D.80608@yandex.ru> 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> <83k2uufdkg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435094251 11817 80.91.229.3 (23 Jun 2015 21:17:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jun 2015 21:17:31 +0000 (UTC) Cc: 20847@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 23 23:17:21 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 1Z7VZB-0004UM-NP for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 23:17:13 +0200 Original-Received: from localhost ([::1]:47450 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7VZA-0000w6-P1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 17:17:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7VZ5-0000sG-BT for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 17:17:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7VZ1-0006rq-7j for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 17:17:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7VZ1-0006rl-2A for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 17:17:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z7VZ0-0005WQ-Di for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 17:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Jun 2015 21:17: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.143509416721154 (code B ref 20847); Tue, 23 Jun 2015 21:17:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 23 Jun 2015 21:16:07 +0000 Original-Received: from localhost ([127.0.0.1]:55625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7VY7-0005V7-0Z for submit@debbugs.gnu.org; Tue, 23 Jun 2015 17:16:07 -0400 Original-Received: from mail-wi0-f177.google.com ([209.85.212.177]:34619) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7VY4-0005UX-L3 for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 17:16:05 -0400 Original-Received: by wicnd19 with SMTP id nd19so117504478wic.1 for <20847@debbugs.gnu.org>; Tue, 23 Jun 2015 14:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=kNB7eUaZHiXnJn466jcrLbdGBjRw7GpI5/eD7m/PA9g=; b=eX6V78BkCBtpCAnqIBQFTIFSCE0UYZDxajV0d/2zioElRacj/fT9vM7hgN9h/qEfZ1 0g9x2fp0L+VWQCm+YnP3sj/3BJ2PdXx0MBUL+cPNoObVPohswCt0J3UVJ5dBRWexfAsx xiGsoT3q2jVl0YIE3vMJ9NpcI/hZ3E98H31KeB+m+ph0LeNS1jX8Pfcfl7k8AAAe+FSh ql+Z9CvpBAsKXGuP3Yomn6hVzwowj9sWJho4J0EQP9dStIxlFZaCc8olzzV5jrZ6tJCb Vz9YPjCS/MuBone+wZwNK2RrbyGY121DsoXo6FQl41JmFPBmiyYgqUfIy4ohWzEz5y/L xzJw== X-Received: by 10.194.77.144 with SMTP id s16mr63186209wjw.145.1435094159141; Tue, 23 Jun 2015 14:15:59 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id um5sm37332943wjc.1.2015.06.23.14.15.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2015 14:15:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83k2uufdkg.fsf@gnu.org> 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:104279 Archived-At: On 06/23/2015 10:07 PM, Eli Zaretskii wrote: > "Now" as in "what Company does now". It very much uses that newline "now". The most recent major change, IIRC, was related to working around the previously mentioned invisible<->display bug. > emacs -Q > M-: (overlay-put (make-overlay 65 66) 'before-string "how\ndo\nyou\ndo?") RET But there's nothing special about newlines here. The display engine probably never "tried" to display the cursor at any of those that are inside the display string. >> 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"? Consider for displaying the cursor at? Allow me to quote yourself: "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." For that heuristic to apply, I'd say first you have to "try" to display it at that position. >> 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. So maybe I misunderstood, and there's no heuristic about newline at the end of visual line coming from an overlay. And that other circumstances conspire to make it seem that way, namely: - Cursor is always displayed after an overlay when it's "inside" it. - We somehow always consider point to be "inside" overlay when it's at the window edge, and an overlay begins there too. Maybe the latter could still be changed. >> (if wouldn't be displayed in the middle of the overlay string, right?). > > Never (unless there's a character with 'cursor' property). Yes, we're not considering this case, for now. >> 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. Inserting characters with overlays applied already? If you're talking about one existing overlay, maybe the behavior should depend on the stickiness of the overlay's bounds. > Again, this case is IMO singular, in that none of the overlay string > characters are visible on that line. Thus "as if...". Maybe it is singular. >> 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. Again, refer to the quote above. And I probably have misunderstood. >> 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. Then the overlay must begin at the edge of the window, and all the cases where your quote (above) applies look like this case. >> But then, maybe I don't really understand what it does. > > I can tell you which parts of code to read, if you want. If you think that's wise.