GNU bug report logs -
#9782
24.0.90; move-to-window-line not taking header line into account
Previous Next
Reported by: David Engster <deng <at> randomsample.de>
Date: Tue, 18 Oct 2011 12:05:02 UTC
Severity: normal
Found in version 24.0.90
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9782 in the body.
You can then email your comments to 9782 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#9782
; Package
emacs
.
(Tue, 18 Oct 2011 12:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
David Engster <deng <at> randomsample.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 18 Oct 2011 12:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#9782
; Package
emacs
.
(Tue, 18 Oct 2011 14:02:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 9782 <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#9782
; Package
emacs
.
(Tue, 18 Oct 2011 14:25:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 9782 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii writes:
>> From: David Engster <deng <at> 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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 18 Oct 2011 16:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
David Engster <deng <at> randomsample.de>
:
bug acknowledged by developer.
(Tue, 18 Oct 2011 16:03:03 GMT)
Full text and
rfc822 format available.
Message #16 received at 9782-done <at> debbugs.gnu.org (full text, mbox):
> From: David Engster <deng <at> randomsample.de>
> Cc: 9782 <at> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 16 Nov 2011 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 219 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.