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

[Dmitry Gutov <dgutov@yandex.ru>]

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'
>> property.
>
> 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
>> `company-pseudo-tooltip-show'.
>
> 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!