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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 20847@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.