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 20:46:59 +0300 Message-ID: <5586F893.2070504@yandex.ru> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> <5586BC71.3080608@yandex.ru> <83ioahhvwk.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 1434908903 3747 80.91.229.3 (21 Jun 2015 17:48:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jun 2015 17:48:23 +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 19:48:12 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 1Z6jLn-0005bT-Tc for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 19:48:12 +0200 Original-Received: from localhost ([::1]:36893 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jLn-00036v-2W for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 13:48:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jLj-00035z-Hf for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 13:48:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6jLe-00049d-F2 for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 13:48:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6jLe-00049X-BG for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 13:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6jLd-0004Ft-VN for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 13:48: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 17:48:01 +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.143490883416295 (code B ref 20847); Sun, 21 Jun 2015 17:48:01 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 21 Jun 2015 17:47:14 +0000 Original-Received: from localhost ([127.0.0.1]:53527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6jKr-0004Ek-Jh for submit@debbugs.gnu.org; Sun, 21 Jun 2015 13:47:14 -0400 Original-Received: from mail-wi0-f173.google.com ([209.85.212.173]:38064) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6jKo-0004ER-37 for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 13:47:11 -0400 Original-Received: by wibdq8 with SMTP id dq8so56344638wib.1 for <20847@debbugs.gnu.org>; Sun, 21 Jun 2015 10:47:04 -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=Yuwww8rjTV1qzFArMkNcSkY75tWTsFENiVHp7gFoMPg=; b=BNuPB3iVl/Wo0stZ7LPmkUKJiSxaAirEXV6wVmZWKX8h7rEvRHF5SP4+yZ8/rKrH/i iHnsHPkFeQd/oFXI1rrPtSlU4jQR88xgnHL2rQHqja9n9Httf52fucWsOpNvKY1ZaEet 9vvcSuC+LFi1sNS87wJtCnihWIkHdbC32wGvPbhXHMIgshjKPC90Igs1s0R9DFkr2QYB oG7wCJlzAHtmRwucQW7AblFKFBYxJf2bJv5TEv7tK4GU63AkH7NPUZHjg0M4G5hEsN9D 0JwZUmprx+MX1hSsF0SZ0AU0+C8R8K4G8wHnitmJZ3zPM5QlmG8Inaw1kVy7iPbmcitF Kukg== X-Received: by 10.194.133.73 with SMTP id pa9mr44813176wjb.148.1434908824498; Sun, 21 Jun 2015 10:47:04 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id ej5sm26619477wjd.22.2015.06.21.10.47.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2015 10:47:04 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83ioahhvwk.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:104181 Archived-At: On 06/21/2015 07:24 PM, Eli Zaretskii wrote: > Ugh... Why doesn't ELPA have the latest code? Because GitHub provides certain niceties as a project (and code) hosting plaform. This has been discussed before. Company is not the only project to host on GitHub and only push releases to ELPA. >> Which character should I put this property on in this situation, then? > > The one before, I think. Like I explained later: I see. But that's going to look confusing: if the cursor appears earlier, the users are going to assume (at least from time to time) that they haven't typed the last character yet. That kind of confusion isn't good for a code completion framework. > I didn't investigate why this happens. Is it important? Suppose I > "fixed" it by having the cursor on the same place in the second > paragraph where it ends up later -- will this be better in some sense? > If so, I will look into it. (It's probably some redisplay > optimization that needs to be disabled in that case.) Not really important. I just thought it might be a detail that would lead you to a different explanation for this bug. Same for the extra questions in the following email. > Sorry, I'm not following, or maybe I don't understand the underlying > issues. (I've re-read that bug, but I don't think it's relevant to > what I'm asking here.) My question is about the newlines that get > inserted into the overlay string. We can't really use a different rendering approach for every distinct layout of the buffer text: I'll go crazy. Originally, the overlay (usually) started after the newline, and the popup was rendered using an overlay spanning the next 10 lines. Now that we've found out that the `display' text property beginning right after that newline can really screw things (make the display value appear twice), the popup overlay begins one character earlier, and includes that character in its display string. If that sounds like an overlay priority war, it pretty much is; except one can configure overlay priorities, but they can't do that for `invisible' vs `display'. > The original buffer text is one > long line, without any newlines, which occupies several screen lines. > Why cannot the overlay string be simply a copy of that text, a single > long string without any newlines? The display engine will display > them with the continuation indicators on the fringes, exactly like it > does for buffer text, and the user will not "lose" those characters at > the end of each line. Can't say I've considered this before, this sounds more complex that what we have now, and depends on lines being wrapped in a certain way. First, what if visual-line-mode is on? Then we'll have to track the presence of it and similar modes. Second, the continuation characters will look out of place (and we'll have to have them for the next 10 lines, right?). Because normally you don't see them, but if the overlay rendering switches to wrapped lines instead of newlines, they will always be present (or rather blink in and out of existence as the popup is displayed or hidden). >> It also simplifies some logic in the code, because sometimes we have to >> do this anyway (when the popup is displayed below the last line, and it >> has no trailing newline). > > You have "to do" what sometimes? Start the popup overlay at the end of the preceding line, and include a newline in its display string (because there's no newline in the buffer). Admittedly, it's a recent development; previously, Company inserted a temporary newline, tracked it, and removed it after completion. And caught its share of bugs because of that.