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 23:01:10 +0300 Message-ID: <55871806.1070903@yandex.ru> References: <868ubgld8y.fsf@yandex.ru> <83mvzvjz3w.fsf@gnu.org> <5586BC71.3080608@yandex.ru> <83ioahhvwk.fsf@gnu.org> <5586F893.2070504@yandex.ru> <83egl5hr0t.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 1434916943 24094 80.91.229.3 (21 Jun 2015 20:02:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jun 2015 20:02: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 22:02: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 1Z6lRT-0004gy-43 for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 22:02:11 +0200 Original-Received: from localhost ([::1]:37184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6lRS-0004oB-7N for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jun 2015 16:02:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6lRO-0004n1-IQ for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 16:02:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z6lRK-0001vR-Hc for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 16:02:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z6lRK-0001vN-Dj for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 16:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z6lRK-0000aH-29 for bug-gnu-emacs@gnu.org; Sun, 21 Jun 2015 16:02: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 20:02: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.14349168842201 (code B ref 20847); Sun, 21 Jun 2015 20:02:01 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 21 Jun 2015 20:01:24 +0000 Original-Received: from localhost ([127.0.0.1]:53618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6lQh-0000ZQ-Nj for submit@debbugs.gnu.org; Sun, 21 Jun 2015 16:01:24 -0400 Original-Received: from mail-wi0-f181.google.com ([209.85.212.181]:36637) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z6lQf-0000ZA-5Q for 20847@debbugs.gnu.org; Sun, 21 Jun 2015 16:01:21 -0400 Original-Received: by wicnd19 with SMTP id nd19so59289447wic.1 for <20847@debbugs.gnu.org>; Sun, 21 Jun 2015 13:01:15 -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=sIycdO7YH9S1yPOK275YFFfoqw5xCxJCfrEWXkAFD18=; b=09nMN0VeCB8aZRjg7AqmIjTGAtJS6NhIqhs8mWGG+Dz/8jm+kelAYNFmeiuQEA5uSW JypRQn3NVLtC1pHSgOp19ckpzK+Q8GM6H6BQtVssHc3Mn8g4Wl8AcdhdC8rMq4fRgLBt xBKJixDtpVaJZGHcNLB39zPjH+uOHtqt7SjlHHHfb81pY4qkW++BQ+mHtCW5nIYbHptX vlkBsNI4e5ZextDGHHTBZhxCvN7PEd7GmDKROy/Gm1FR/9TGwmoWdwa0HCUocspUiZzY NXPbqQAAif+PxRBV37m3E8NrQGH55ai1LOdE9kHRgXsbJLNwx9f1KYI1mek1cKRibyke nyEg== X-Received: by 10.180.73.10 with SMTP id h10mr25889087wiv.3.1434916875344; Sun, 21 Jun 2015 13:01:15 -0700 (PDT) Original-Received: from [192.168.1.2] ([82.102.93.54]) by mx.google.com with ESMTPSA id bz2sm10670200wjc.25.2015.06.21.13.01.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Jun 2015 13:01:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83egl5hr0t.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:104190 Archived-At: On 06/21/2015 09:09 PM, Eli Zaretskii wrote: > No, I expect the cursor to be drawn on the fringe, like the user > expects. (Or maybe I misunderstand what you meant by "earlier".) You > should give the 'cursor' property an integer value, so that it > "covers" the buffer position of the newline. Ok, thanks. I forgot that `cursor' can have an integer value. > There are only 2 situations, from your POV: either a line goes all the > way to the window edge, or it doesn't. Could you suggest the best way to check whether the former is the case? (>= (car (posn-col-row (posn-at-point))) (window-width)) > The former can happen either if there's a newline that ends a line, > or if word-wrap is in effect. Does that constitute at least three different cases we'd need to handle? - Not near the window edge - near the edge and newline - near the edge and no newline? > Yes, there could be such artifacts, but IMO losing some of the text is > worse. I'm not sure what you mean by "losing some of the text". > And the problems you describe will be only on the lines > actually used for the popup; the rest of the lines, which just copy > buffer text into an overlay string, will look exactly like they did > before, including the continuation markers. Err, why this distinction? If anything, I guess we could "replace" only the first newline inside the overlay display string with wrapping, while keeping the rest as newlines, because they are irrelevant to this bug. >> 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). > > I had no problems with that newline. Sure. In those circumstances, moving point to the end of the overlay would be a no-op anyway.