* bug#9782: 24.0.90; move-to-window-line not taking header line into account @ 2011-10-18 12:03 David Engster 2011-10-18 14:00 ` Eli Zaretskii 0 siblings, 1 reply; 4+ messages in thread From: David Engster @ 2011-10-18 12:03 UTC (permalink / raw) To: 9782 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#9782: 24.0.90; move-to-window-line not taking header line into account 2011-10-18 12:03 bug#9782: 24.0.90; move-to-window-line not taking header line into account David Engster @ 2011-10-18 14:00 ` Eli Zaretskii 2011-10-18 14:23 ` David Engster 0 siblings, 1 reply; 4+ messages in thread From: Eli Zaretskii @ 2011-10-18 14:00 UTC (permalink / raw) To: David Engster; +Cc: 9782 > 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#9782: 24.0.90; move-to-window-line not taking header line into account 2011-10-18 14:00 ` Eli Zaretskii @ 2011-10-18 14:23 ` David Engster 2011-10-18 16:00 ` Eli Zaretskii 0 siblings, 1 reply; 4+ messages in thread From: David Engster @ 2011-10-18 14:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 9782 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#9782: 24.0.90; move-to-window-line not taking header line into account 2011-10-18 14:23 ` David Engster @ 2011-10-18 16:00 ` Eli Zaretskii 0 siblings, 0 replies; 4+ messages in thread From: Eli Zaretskii @ 2011-10-18 16:00 UTC (permalink / raw) To: David Engster; +Cc: 9782-done > From: David Engster <deng@randomsample.de> > Cc: 9782@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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-10-18 16:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-18 12:03 bug#9782: 24.0.90; move-to-window-line not taking header line into account David Engster 2011-10-18 14:00 ` Eli Zaretskii 2011-10-18 14:23 ` David Engster 2011-10-18 16:00 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).