[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
From: |
David Engster |
Subject: |
bug#9782: 24.0.90; move-to-window-line not taking header line into account |
Date: |
Tue, 18 Oct 2011 16:23:37 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (darwin) |
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