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

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/30/2015 08:46 PM, Eli Zaretskii wrote:

> If so, does "point" here mean that buffer position of that rightmost
> character?

Let's say yes.

> 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.)

That's why I asked. Creating a yet another variation of this function 
isn't going be very fun, especially when it's hard to test automatically.

>> Why not prefer the former?
>
> Insertion point, I think.  If you type characters, they will appear on
> the next line, which is confusing.

Isn't it the same in the absence of any overlays, if point is under the 
edge of the window (and so the cursor is displayed on the margin)?

Nothing particularly confusing about that.

> 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.

I see.

>> 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.

Maybe it could be performed in two stages: on some higher level, you 
maybe adjust the value of point if it has ventured beyond the currently 
visible area.

On the lower level, when drawing glyphs, you can adjust the placement of 
cursor, but without affecting point. Admittedly, that sounds like a 
non-trivial change.

> 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.

What I said is, if it's a hack, then I want a hack that will work today.

But if a "proper" solution is introduced (one that won't make the popup 
code in Company more complex overall), then I'm not above telling all 
users to either disable bidi, or upgrade to the latest Emacs.