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/20/2015 02:51 PM, Eli Zaretskii wrote:

> In a nutshell, when a screen line ends in a newline that comes from an
> overlay string, we don't want to display the cursor on that line.  The
> reasons are heuristic, but they give good results, and we used this
> heuristic for a very long time, so changing it now is out of question.

Do you have a scenario in mind that performs better under the current 
behavior?

> Due to this, when you type Backspace to delete "l" in "hell", and the
> Company post-command-hook runs and puts an overlay string on the same
> line that begins with a newline, the display engine decides, after
> redrawing the window, that it doesn't want to put the cursor there,
> and looks for an alternative place.  The first such place is after the
> overlay string, so point is moved there.

I can understand the scenario until now, but why move point?

Displaying cursor in a different place is relatively fine, but moving 
the point is destructive.

> The font-lock part of this riddle is that when font-lock-mode is
> active in the buffer, making any changes to buffer text cause JIT Lock
> to spring to action, which doesn't really do anything, but disables a
> certain redisplay optimization, which bypasses the above test.

Sounds messy.

> My suggestion would be to use the 'cursor' property on the overlay
> string in some place where it could be picked up by the display engine
> (i.e. not on a newline), to countermand this problem.

See the bottom of `company--replacement-string'. If `cursor' is applied 
unconditionally, and if I change the arguments 0 and 1 to 1 and 2, on 
step 6 the cursor is displayed at the beginning of the next line (so we 
know the change has effect), but the second problem (after step 9) is 
still present.

> E.g., perhaps
> begin the overlay string a few characters earlier, so that it replaces
> part of buffer text in "hel", and have the 'cursor' property on that
> part of the string.

That's doable, even if I don't like the extra complexity. Are you sure 
about this?

> I still think the overlay string is constructed incorrectly in this
> case, something that should be fixed in Company.  The above special
> setting of 'cursor' could be part of that fix.

Do you also have explanations for the following?

- The bug only manifests after the step 9 (backspacing), whereas the 
whole explanation seems to apply to the step 6 as well. Yet, point stays 
in place there.

- With bidi-display-reordering set to nil, there's no bug.