GNU bug report logs - #9782
24.0.90; move-to-window-line not taking header line into account

Previous Next

Package: emacs;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: David Engster <deng <at> randomsample.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.90; move-to-window-line not taking header line into account
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.


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: Eli Zaretskii <eliz <at> gnu.org>
To: David Engster <deng <at> randomsample.de>
Cc: 9782 <at> debbugs.gnu.org
Subject: Re: 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 <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):

From: David Engster <deng <at> randomsample.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9782 <at> debbugs.gnu.org
Subject: Re: bug#9782: 24.0.90;
	move-to-window-line not taking header line into account
Date: Tue, 18 Oct 2011 16:23:37 +0200
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: Eli Zaretskii <eliz <at> gnu.org>
To: David Engster <deng <at> randomsample.de>
Cc: 9782-done <at> debbugs.gnu.org
Subject: Re: bug#9782: 24.0.90;
	move-to-window-line not taking header line into account
Date: Tue, 18 Oct 2011 18:00:39 +0200
> 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.