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: Sun, 21 Jun 2015 16:56:56 +0300 Message-ID: <5586C2A8.1020904@yandex.ru> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> <83wpyyiond.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 1434895106 20931 80.91.229.3 (21 Jun 2015 13:58:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jun 2015 13:58:26 +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 Sun Jun 21 15:58:15 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 1Z6flE-0001d3-EV for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 15:58:12 +0200 Original-Received: from localhost ([::1]:36374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6flE-0005Zr-0X for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 09:58:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6fl9-0005ZL-S2 for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 09:58:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6fl4-0002Am-On for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 09:58:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6fl4-0002AX-LN for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 09:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6fl4-0007Mv-4l for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 09:58: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: Sun, 21 Jun 2015 13:58: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.143489502928269 (code B ref 20847); Sun, 21 Jun 2015 13:58:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 21 Jun 2015 13:57:09 +0000 Original-Received: from localhost ([127.0.0.1]:53443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6fkC-0007Ls-Ub for submit@debbugs.gnu.org; Sun, 21 Jun 2015 09:57:09 -0400 Original-Received: from mail-wi0-f173.google.com ([209.85.212.173]:36134) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6fkA-0007LM-4x for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 09:57:07 -0400 Original-Received: by wicnd19 with SMTP id nd19so55082370wic.1 for <20847@debbugs.gnu.org>; Sun, 21 Jun 2015 06:57: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=kBXVuyRImSi/FkAXdjM4d4Q1IipeRcMXjfLlP3wJAEg=; b=YadnXB10Yy2SdKDdMapQH6+LbTeFblnTkLXyHiB++v1y0W8jURuBdYGzu5GNZdDmDE 8rY9xeLlmDM0izjJaocZZvkUml/wb+X3ios9cOlTWzuqKwzkvtcjRmbsY60ot8GYX8Ad Q1jvmLL0Enq3ZSmDdijs9/ioiw8VDpohaegYqkTOeFGfv2UqKM42IGIhttlzrBBz41lr J7n9/l16wLPHOlwh51M6DJwmedsLbEfMWOZKxDwUkzWaWlIG+8LaF5fABkC+Yx7VTjgk nX38hel1S8XWEwrxXuQkIBnf/wUqCb0D/E4KcgfOxmycEm3DkO7LR1YXzrr1vRTR5rWq 7YTQ== X-Received: by 10.180.37.229 with SMTP id b5mr23396134wik.16.1434895020502; Sun, 21 Jun 2015 06:57:00 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id c11sm12573120wib.1.2015.06.21.06.56.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2015 06:57:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83wpyyiond.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:104171 Archived-At: On 06/20/2015 02:51 PM, Eli Zaretskii wrote: > 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. The > reasons are heuristic, but they give good results, and we used this > heuristic for a very long time, so changing it now is out of question. Do you have a scenario in mind that performs better under the current behavior? > Due to this, when you type Backspace to delete "l" in "hell", and the > Company post-command-hook runs and puts an overlay string on the same > line that begins with a newline, the display engine decides, after > redrawing the window, that it doesn't want to put the cursor there, > and looks for an alternative place. The first such place is after the > overlay string, so point is moved there. I can understand the scenario until now, but why move point? Displaying cursor in a different place is relatively fine, but moving the point is destructive. > The font-lock part of this riddle is that when font-lock-mode is > active in the buffer, making any changes to buffer text cause JIT Lock > to spring to action, which doesn't really do anything, but disables a > certain redisplay optimization, which bypasses the above test. Sounds messy. > My suggestion would be to use the 'cursor' property on the overlay > string in some place where it could be picked up by the display engine > (i.e. not on a newline), to countermand this problem. 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. > E.g., perhaps > begin the overlay string a few characters earlier, so that it replaces > part of buffer text in "hel", and have the 'cursor' property on that > part of the string. That's doable, even if I don't like the extra complexity. Are you sure about this? > I still think the overlay string is constructed incorrectly in this > case, something that should be fixed in Company. The above special > setting of 'cursor' could be part of that fix. Do you also have explanations for the following? - 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. - With bidi-display-reordering set to nil, there's no bug.