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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27427: 26.0.50; Native line numbers lead to display error in company


From: Eli Zaretskii
Subject: bug#27427: 26.0.50; Native line numbers lead to display error in company-mode popup
Date: Wed, 28 Jun 2017 21:56:38 +0300

> Date: Wed, 28 Jun 2017 20:35:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: dgutov@yandex.ru, alexanderm@web.de, 27427@debbugs.gnu.org
> 
>  > Alas, that is not how redisplay works.  For starters, you seem to
>  > assume that it always traverses all the screen lines of a window (thus
>  > "on the next buffer line" etc.).  But that is only so when a window
>  > needs a complete redisplay, and the display engine tries very hard to
>  > avoid that.  Many times it only redraws some of the lines, sometimes
>  > just one line.  If that line is not the first line of the popup, how
>  > will the display engine know that at some previous buffer position
>  > there is an overlay?
> 
> Because an application would include that very line in the 'tty-popup'
> overlay BEG...END range and the display engine has to know how to handle
> an overlay that spans multiple lines.  Right?

I cannot answer this question, it's too general.  And doesn't
company-mode use before- and after-strings, at least sometimes?  Those
have BEG and END the same value, so you must hit that position to know
something's there.

> Then consider the ‘tty-popup-frames’ list approach: It would have to
> remember the start and end glyph matrix positions of the popup frame as
> drawn the last time and if these intersect with what has been redrawn in
> an optimized way then it would have to (1) restore the old contents of
> the popup frame by the real buffer text, if necessary and (2) rewrite
> popup frame parts, if necessary.

That'll cause flickering, as users will see "incorrect" stuff
momentarily visible until the popup is restored.

Moreover, the "redrawn" part is in dispnew.c routines, called long
after xdisp.c did its job.

I think the only workable idea is to create a special kind of window
that is not part of the usual window tree, and let the display engine
consider those windows after the "normal" ones have been.  Do popup
frames need to support windows, mode lines, etc?  Or are they more
like tooltips -- one window and no decorations?





reply via email to

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