[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9782: 24.0.90; move-to-window-line not taking header line into accou
bug#9782: 24.0.90; move-to-window-line not taking header line into account
Tue, 18 Oct 2011 16:23:37 +0200
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (darwin)
Eli Zaretskii writes:
>> From: David Engster <address@hidden>
>> Date: Tue, 18 Oct 2011 14:03:13 +0200
>> * 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
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.