bug#20847: [display engine] 25.0.50; company-mode popup makes point jump to an entirely different location

[Dmitry Gutov]

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.