[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20847: [display engine] 25.0.50; company-mode popup makes point jump

From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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 ""))
      ;; 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)))))

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]