[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: |
Eli Zaretskii |
Subject: |
bug#9782: 24.0.90; move-to-window-line not taking header line into account |
Date: |
Tue, 18 Oct 2011 10:00:11 -0400 |
> 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.