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

[Dmitry Gutov <dgutov@yandex.ru>]

On 05.05.2013 19:53, Eli Zaretskii wrote:
>> Date: Sun, 05 May 2013 06:59:48 +0400
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: emacs-devel@gnu.org
>>
>>>> Simply adjusting the row number for presence of `header-line-format'
>>>> won't do, because company strives to support Emacs 23 (and maybe even
>>>> 22), and `post-actual-col-row' behavior was different before the
>>>> revision 106022.

>> But it's a seemingly reasonable piece of code, it worked, and your
>> change made it break in some peculiar special case important to some
>> users.
>
> That's not true.  It was not a peculiar special case. The function did
> not behave according to its contract, and my change fixed that.

Comparing the descriptions of `move-to-window-line' and 
`posn-actual-col-row', it doesn't seem obvious that one considers the 
header line part of the window, and another doesn't. The words "row" and 
"line" are often synonymous in English.

>> So I thought you could suggest how that code could be written
>> better/faster/stronger instead.
>
> Well, how about telling more about what you need to do, and in
> particular why do you need to go to the place you go by row and
> column?  Why not use posn-point, for example?  For that matter, why
> not use buffer positions directly?

In short, we're painting a rectangle near point, using an overlay. So 
columns and rows are a natural way to think about the problem.

Historically, the overlay rectangle is called "pseudo-tooltip" here.

https://raw.github.com/company-mode/company-mode/master/company.el

`company-pseudo-tooltip-show-at-point' passes the current row and column 
to `company-pseudo-tooltip-show', which collects are required lines and 
prepares the `before-string' for the overlay.

These two would be the easiest to convert to direct point manipulation, 
except for the detail that they calculate, use and store the beginning 
column in the overlay property, for use later.

`company--pseudo-tooltip-height' calculates the appropriate rectangle 
height, based on the current row and the inner height of the window.

`company--electric-do' (somewhat unrelated) calls `recenter' using the 
value returned by `posn-actual-col-row'.

`company-select-mouse' and `company--inside-tooltip-p' handle mouse 
interaction with the rectangle, comparing the coordinates of the mouse 
click with the coordinates and dimensions of the rectangle (some of them 
saved previously; the current row is again retrieved using 
`posn-actual-col-row').

To conclude, I see two alternative solutions, both require 
re-implementing `company-row':

1) Using `move-to-window-line', `vertical-motion' and a counter.

2) Call `posn-at-point' and `posn-actual-col-row' in `company--row' 
twice, for the current point, and for the point at the top of the window 
(use `move-to-window-line' here), then subtract.

`posn-at-point' is relatively slow already, so the second option seems 
to be the worst one.