[Top][All Lists]

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

Re: bug#9782: 24.0.90; move-to-window-line not taking header line into a

From: Dmitry Gutov
Subject: Re: bug#9782: 24.0.90; move-to-window-line not taking header line into account
Date: Tue, 07 May 2013 21:19:59 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

On 07.05.2013 20:50, Eli Zaretskii wrote:
There's just one overlay, and it covers all of them (plus all text on
the sides).

Sorry, I don't understand.  Perhaps we are talking about two different
things.  Are you talking about the menu-like display of possible
completions, shown to the user to let her select one of the
candidates?  If so, how can they be a single overlay string, when they
are shown in different screen lines?  Are you also copying the buffer
text into the overlay string or something?  Otherwise I don't
understand how can you show a multi-line overlay string and still have
buffer text be seen.  What am I missing?

Yes. Yes, the whole lines are copied, modified in the right place and then shown using `before-string' overlay property (the original text is hidden with `invisible' -> t).

Maybe what you're suggesting would be an improvement (I see
dropdown-list.el also does that), but the current approach works fast
enough, and it would have the advantage in a hypothetical situation when
some of the text we need to "draw on" is already rendered via `display'

I don't see any advantages even in that situation, but maybe I'm
misunderstanding what you mean.

If some of the lines in the middle of the modified region are doing freaky things with `display', `before-string', etc, it complicates our ability to position each overlay on the right column visually (`current-column' only considers physical characters, the "right" column may turn out to be inside a `before-string' string, stuff like that).

Making one overlay spread over all those lines means we can pre-process all lines, only take the physical text (plus composed chars), and mostly disregard third-party overlays.

My suggestion is to make each completion candidate a separate display
string, then the event position list will tell you directly which
string was clicked.

I understood that, thank you. It would indeed allow us to skirt the row <-> line issue, at the cost of pervasive changes in the code.

I mean fixing the row number <-> line number discrepancy from the other
side, by making a wrapper for `move-to-window-line', the only function
of the bunch that deals with line numbers. It's used in

count-screen-lines also deals with line numbers.

Yes, but that would be fixing the discrepancy from the other side, and then `company--row', reimplemented using `count-screen-lines', would conflict with row values from mouse events, so this will only work when we don't need to compare them (i.e. when using multiple overlays).

Anyway, I think you now have the information needed to fix company.el,
and can select the implementation that you like best.

I guess so. Thanks for the discussion!

reply via email to

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