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: Tue, 23 Jun 2015 21:44:58 +0300 Message-ID: <5589A92A.5080709@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> 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 1435085182 26204 80.91.229.3 (23 Jun 2015 18:46:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Jun 2015 18:46:22 +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 20:46: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 1Z7TD0-0005d7-4h for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 20:46:10 +0200 Original-Received: from localhost ([::1]:46987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TCz-0004G9-Jo for geb-bug-gnu-emacs@m.gmane.org; Tue, 23 Jun 2015 14:46:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TCv-0004Fh-Pc for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 14:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7TCs-0007zO-Is for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 14:46:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7TCs-0007zI-Ex for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 14:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z7TCs-0001v8-6g for bug-gnu-emacs@gnu.org; Tue, 23 Jun 2015 14:46: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 18:46: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.14350851107304 (code B ref 20847); Tue, 23 Jun 2015 18:46:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 23 Jun 2015 18:45:10 +0000 Original-Received: from localhost ([127.0.0.1]:55575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7TC1-0001th-1Z for submit@debbugs.gnu.org; Tue, 23 Jun 2015 14:45:10 -0400 Original-Received: from mail-wi0-f177.google.com ([209.85.212.177]:34518) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z7TBx-0001st-Ry for 20847@debbugs.gnu.org; Tue, 23 Jun 2015 14:45:06 -0400 Original-Received: by wicnd19 with SMTP id nd19so114258712wic.1 for <20847@debbugs.gnu.org>; Tue, 23 Jun 2015 11:45:00 -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=Jbv8s+WKkveO/pyOpStxtZHMxx99v3mSSM6PIFwF6nw=; b=MiP+cWETEnFWiIUDnTqjDfGtAumOuq1P6yauWUEIy+SgQfNAhiU/juUrxj7v4LGnQD du7pa1LfZ7a3pYWF6J+nRezjt9O84dkuBcZrYfk8Jn4LAJbYV68o72pllPMn2GM0CL7z rD0KUaprNri01JjumEMV2N+kpPQ6Tzt/d8IdiSYr2qTQMvsAKaIm+Xa5XH5Q83Wkunfv K2ccqPK24bE2iO2olPgMRQmAvMeB4i5uVA+dljERKqp5eQ/bxbpqfL2etTkMVsG+qu0S 3AyJDkX+pJHMEck1uT+U6/xctBqUB+VkOKzt3VJx6Kmo5z7vVBxYxyTJVcBT4N5eakuz v6Og== X-Received: by 10.194.2.137 with SMTP id 9mr52894438wju.75.1435085100143; Tue, 23 Jun 2015 11:45:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id js3sm36837695wjc.5.2015.06.23.11.44.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2015 11:44:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83vbeefkf8.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:104275 Archived-At: 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"? If the line after the current has a `display' property, it could still lead to the problem like bug#18285. However, `M-x report-emacs-bug' buffer (which was the main example for that bug) doesn't have particularly long lines, so we could hope the workaround won't be triggered there. But anyway, wrong rendering is still better than moving point to a different place. >> 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. 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. If it starts earlier, then the cursor might be displayed before or after (if wouldn't be displayed in the middle of the overlay string, right?). > 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 seems consistent with the logic of expecting the cursor "to be displayed 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. If it ends later, why would we even try to display the cursor at that newline in the first place? >> 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. But then, maybe I don't really understand what it does.