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: Mon, 29 Jun 2015 18:48:09 +0300 Message-ID: <559168B9.8070403@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> <5589CC8D.80608@yandex.ru> <83pp4ldqq9.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 1435592965 22977 80.91.229.3 (29 Jun 2015 15:49:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Jun 2015 15:49:25 +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 Mon Jun 29 17:49:14 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 1Z9bJ2-0008NL-Of for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jun 2015 17:49:13 +0200 Original-Received: from localhost ([::1]:42830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9bJ2-000137-8c for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jun 2015 11:49:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9bIx-00010a-JB for bug-gnu-emacs@gnu.org; Mon, 29 Jun 2015 11:49:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9bIs-0004t3-K5 for bug-gnu-emacs@gnu.org; Mon, 29 Jun 2015 11:49:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9bIs-0004sq-El for bug-gnu-emacs@gnu.org; Mon, 29 Jun 2015 11:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z9bIs-000205-31 for bug-gnu-emacs@gnu.org; Mon, 29 Jun 2015 11:49: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: Mon, 29 Jun 2015 15:49: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.14355929017643 (code B ref 20847); Mon, 29 Jun 2015 15:49:01 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 29 Jun 2015 15:48:21 +0000 Original-Received: from localhost ([127.0.0.1]:33165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9bIC-0001zC-Ee for submit@debbugs.gnu.org; Mon, 29 Jun 2015 11:48:21 -0400 Original-Received: from mail-wi0-f174.google.com ([209.85.212.174]:33617) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9bI9-0001ys-Co for 20847@debbugs.gnu.org; Mon, 29 Jun 2015 11:48:18 -0400 Original-Received: by wiwl6 with SMTP id l6so104152128wiw.0 for <20847@debbugs.gnu.org>; Mon, 29 Jun 2015 08:48:11 -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=YDa5oR00Bk/A0siMtmZWqycvW3xuXwX/6qAJ4Fn0+gg=; b=hPOVAOtxM3DpRRDSa7APOq17J9ZWXrrsLnC/JSLFRFcFW97qjlGasWTGZWO1rwtRqO u+yaTRXoe8AR2+hoFGI+GVI5FnN+xwPaH3OVtTFaTy2syMr+kx9O/km/J534uNE0xJw6 b5mgr7qrnd/E0YnXnTxbnZ11f9waQzLiNV7/kjyi199RehwcQRfj1jK/M+jl3unNzQrh fsYojwZDfH5mAjoHp32eLkElbcbnA3tKveROKotY6Sg1MMEhPiC0oRZpCaHwq0cJiZly MH3u9ukJkfdC0isUGjv1OIPlWkQilOyp4iNov56tOtSn+TZVLlozZBgGJ9xAeayfTB2Q hCFw== X-Received: by 10.180.77.233 with SMTP id v9mr18959700wiw.87.1435592891755; Mon, 29 Jun 2015 08:48:11 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id q4sm64529687wju.14.2015.06.29.08.48.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2015 08:48:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <83pp4ldqq9.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:104498 Archived-At: On 06/24/2015 07:18 PM, Eli Zaretskii wrote: > Yes, and I was asking whether in this specific case it could refrain > from doing that. (And yes, I understand that doing so would be > additional complexity for you.) Probably yes. But the problem is not only in complexity, but also in the lack of testability (it's not easy to write automatic checks to see if each case behaves as expected; or rather, virtually impossible). Chiefly, I need a reliable predicate. Say I have computed the current visual column of point. What do I compare it to? We have this function to determine the "usable" part of the window's width: (defun company--window-width () (let ((ww (window-body-width))) ;; Account for the line continuation column. (when (zerop (cadr (window-fringes))) (cl-decf ww)) (unless (or (display-graphic-p) (version< "24.3.1" emacs-version)) ;; Emacs 24.3 and earlier included margins ;; in window-width when in TTY. (cl-decf ww (let ((margins (window-margins))) (+ (or (car margins) 0) (or (cdr margins) 0))))) (when (and word-wrap (version< emacs-version "24.4.51.5")) ;; http://debbugs.gnu.org/19300 (cl-decf ww)) ;; whitespace-mode with newline-mark (when (and buffer-display-table (aref buffer-display-table ?\n)) (cl-decf ww (1- (length (aref buffer-display-table ?\n))))) ww)) Do I compare the visual column against the value it returns, or against straight (window-body-width), or against something in between? > Yes, it did. When the display engine needs to decide where to put the > cursor, it examines all the screen lines whose buffer positions are > around point. So in this case, it did examine all those lines that > came from an overlay string, and rejected them all. We could say that if the positions were rejected for other reasons, then, for the purposes of this discussion, they weren't considered for displaying the cursor at. > That's correct, but the heuristic applies to the line where the > overlay string ends, when it ends with a newline that comes from the > overlay string. When this happens, we could place the cursor either > at the end of the line with that newline, or at the beginning of the > next line. We prefer the latter. Why not prefer the former? And use the margin if the cursor goes behind the edge as a result. Unless there are cases which would lead to accidental point movements with this choice as well, this would seem like a better one. > I tried to do that, but unfortunately, when the display engine gets to > the point where it needs to place the cursor, it lacks information for > treating this situation specially. That's because the information > about the overlay is long gone, and the newline didn't leave any > glyphs on the screen. How is the heuristic applied, then? It somehow needs to know, IIUC, that a string coming from a overlay is there. > Yes. And that's exactly the problem: we would like to treat this case > differently, but don't have the necessary information to do so. > > What I need to do so is (1) the starting and ending point of the > overlay which begot the string, and (2) the fact that the string > begins with a newline, or some handle for the string itself. None of > that is available at the point where we decide whether this line is > "appropriate" for the cursor. Maybe the decision where to put the cursor should be made earlier, then. > It's not up to me, it's up to you. If you want to understand the gory > details without myself standing in between (and maybe describing some > things inaccurately or not clearly enough), then I will gladly tell > you where to look. I'm also okay with describing it for you as best I > can, like I did until now. It's your call. I wouldn't mind taking a glance (just out of curiosity, or for a distant future reference), but you'll most likely have to continue translating anyway.