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: Tue, 23 Jun 2015 00:06:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

On 06/22/2015 07:26 PM, Eli Zaretskii wrote:

This doesn't seem to have any effect, though. Adding

        (when (eq ?\n (char-after (overlay-start ov)))
          (let ((inhibit-modification-hooks t))
            (put-text-property (overlay-start ov) (1+ (overlay-start ov))
'cursor t)))

to the end of company-pseudo-tooltip-unhide creates no change in the
behavior.

That's because I have yet to write the code to support that ;-)

I'm not sure I like that idea. If I have to write a workaround (this definitely feels like it), I'd rather write a workaround that will work in the current Emacs releases too. (If I manage to, of course).

And supporting `cursor' on buffer text newline but not on overlay display string newline feels like adding a yet-another edge case.

Will do next; meanwhile, could you perhaps send the above as diffs
relatively to whatever version of company.el you want me to test this
with?  TIA.

Maybe after I exhaust the other approaches.

Going back to your earlier message, I'm actually not sure I agree with this:

> Any scenario where a screen line ends in a newline that comes from an
> overlay string [performs better under the current behavior].  Try
> several such scenarios, and then tell me whether
> the place we display the cursor looks better than the alternative.

The current example shows that it's better to display the cursor on the margin, rather than after the overlay. What are the examples where this is not true? Are those cases where the said newline is not at the beginning of the overlay?

Even if cursor would look weird in some case, at least point is not forcibly moved to a different position.





reply via email to

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