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

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

[David Engster]

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.


Cheers,
David

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

[Eli Zaretskii]

> 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?

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.

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

[David Engster]

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

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Cc: 9782@debbugs.gnu.org
> Date: Tue, 18 Oct 2011 16:23:37 +0200
> 
> 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.

I'm closing the bug report.  My opinion is that company-mode should
either change the way it computes the line to move to, or account for
the header-line itself (e.g., by looking at the value of
header-line-format).  If the author of that package disagrees, I
suggest that he or she starts a discussion on emacs-devel.

Thanks.