bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Sun, 21 Jun 2015 16:56:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.





reply via email to

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