[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: Tue, 30 Jun 2015 22:41:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

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

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

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.

reply via email to

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