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

[David Engster <deng@randomsample.de>]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Tue, 18 Oct 2011 14:03:13 +0200
>> 
>
>> Recipe:
>> 
>> * emacs -Q
>> 
>> * Enter in scratch buffer:
>> 
>> (move-to-window-line (cdr (posn-actual-col-row (posn-at-point))))
>> 
>> and enter an additional newline so this is not the last line in the buffer.
>> 
>> * Move behind last bracket an hit C-x C-e
>> 
>> * Cursor will move to beginning of line, as expected.
>> 
>> * Now do M-: (setq header-line-format "") RET
>> 
>> * Evaluate the above again. You'll see that cursor now will move to the
>>   beginning of the next line, which is wrong.
>> 
>> 
>> This behavior occurs since rev. 106022, which fixed posn-actual-col-row
>> when a header-line is active, but it seems move-to-window-line now has
>> to be fixed as well.
>
> Please provide some arguments as to why the current behavior is wrong.
>
> posn-actual-col-row returns a _row_ derived from a pixel position,
> while move-to-window-line accepts a _line_number_ starting from the
> beginning of the text displayed in the window.  These two are not the
> same.  Unless I'm mistaken, I see many users of move-to-window-line
> that would break if we make the change you suggest.  E.g., what will
> happen to code that does this:
>
>   (move-to-window-line 0)
>
> when there's a header line in the buffer, if your suggestion is
> implemented?

Yes, this would be wrong, obviously.

> Put it another way, the posn-* family of function deals with mouse
> events, which are inherently oblivious to where text is displayed and
> where we have window decorations.  By contrast, move-to-window-line
> belongs to a different family of functions, one that deals with lines
> of text.
>
> Please show where this reasoning is wrong.

I can't. My report was motivated by seeing that the tooltip display of
company-mode (currently in ELPA) broke due to the change in
posn-actual-col-row. Company-mode happens to depend on the above test
case, that means it first determines the actual row at point, moves to
(1+ row) through move-to-window-line and then displays the overlay
there. I don't know why it chooses this way to do this, but it has
worked for years, so I figured move-to-window-line has to be fixed.  If
this new behavior is the correct one, then please close this report and
I will send a bug report to the author of company-mode.

Thanks,
David