From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii 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, 30 Jun 2015 20:46:29 +0300 Message-ID: <83fv592ioa.fsf@gnu.org> 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> <559168B9.8070403@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1435686524 20014 80.91.229.3 (30 Jun 2015 17:48:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jun 2015 17:48:44 +0000 (UTC) Cc: 20847@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 30 19:48:34 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 1Z9ze3-0003lm-8d for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jun 2015 19:48:31 +0200 Original-Received: from localhost ([::1]:48072 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9ze2-00013p-OG for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Jun 2015 13:48:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9zdf-0000kA-Di for bug-gnu-emacs@gnu.org; Tue, 30 Jun 2015 13:48:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9zdb-00035y-9Y for bug-gnu-emacs@gnu.org; Tue, 30 Jun 2015 13:48:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9zdb-00035n-6X for bug-gnu-emacs@gnu.org; Tue, 30 Jun 2015 13:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Z9zda-0002k9-Jz for bug-gnu-emacs@gnu.org; Tue, 30 Jun 2015 13:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Jun 2015 17:48: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.143568643710482 (code B ref 20847); Tue, 30 Jun 2015 17:48:02 +0000 Original-Received: (at 20847) by debbugs.gnu.org; 30 Jun 2015 17:47:17 +0000 Original-Received: from localhost ([127.0.0.1]:34716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9zcp-0002iz-UP for submit@debbugs.gnu.org; Tue, 30 Jun 2015 13:47:16 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:44605) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Z9zcm-0002ik-Th for 20847@debbugs.gnu.org; Tue, 30 Jun 2015 13:47:14 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NQR00J00QMBUT00@a-mtaout20.012.net.il> for 20847@debbugs.gnu.org; Tue, 30 Jun 2015 20:46:26 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQR00JPBQPBKP60@a-mtaout20.012.net.il>; Tue, 30 Jun 2015 20:46:26 +0300 (IDT) In-reply-to: <559168B9.8070403@yandex.ru> X-012-Sender: halo1@inter.net.il 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:104540 Archived-At: > Cc: 20847@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 29 Jun 2015 18:48:09 +0300 > > Chiefly, I need a reliable predicate. Say I have computed the current > visual column of point. What do I compare it to? Are we talking about detecting the situation where the last (rightmost) character displayed on a visual line leaves no space for the newline, therefore forcing the newline be displayed on the fringe? If so, does "point" here mean that buffer position of that rightmost character? > (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? In general, you compare with the value it returns, I think. But I will need to think about this some more. (The issue that bothers me is the width of that last character -- it could be wider than one column. Also, I think the width of the next "display element", the one that will be displayed on the next visual line, might affect the issue.) > > 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. They were rejected for the reason we are discussing, not for other reasons. > > 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? Insertion point, I think. If you type characters, they will appear on the next line, which is confusing. > > 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. It does know that, but that's all it knows. Specifically, the last examined string position is recorded in the "glyph row" structure; when that is non-negative, we know that there's some string there. If a glyph produced from the string is available, then we can also access the string itself, but in the case we are discussing there are no glyphs. > > 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. I don't see how this is possible: you cannot place the cursor on a visual line before you have fully laid out that line. And that's what the code does: it invokes the function that finds where to place the cursor immediately after layout of the line is completed. It might be possible to record more information, though, and use that to make the right decisions. But once again, you wanted a solution that will work with currently released Emacs, so such changes are out of scope for now.