--- Begin Message ---
|
Subject: |
Bug in what-page |
|
Date: |
Tue, 2 Jan 2024 11:39:22 +0100 |
Hello,
The Emacs manual says:
"M-x what-page
Display the page number of point, and the line number within that page."
I would argue that this is the intended function, since that is what
GNU Emacs did before 2010, and it is the same as "What Page" in the
original TECO Emacs.
Bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6825 noted that the
line number was wrong if the cursor was not at the beginning of a
line. There was a fix for this, but the fix only works for the first
page. In subsequent pages, the line number is no longer relative to
the current page.
I'm attaching a patch which restores the original function and also
fixes the bug. The updated test checks this. I also updated the
what-page doc string to more clearly explain what line numbers are
reported.
what-line.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#68215: Bug in what-page |
|
Date: |
Sat, 13 Jan 2024 12:10:24 +0200 |
> From: Lars Brinkhoff <lars.brinkhoff@gmail.com>
> Date: Thu, 11 Jan 2024 14:49:58 +0100
> Cc: 68215@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> wrote:
> > It should be a simple matter to countermand this special-casing in
> > what-page, while still using count-lines. Or am I missing something?
>
> That's probably better. I'm attaching an updated patch which uses
> count-lines instead. It countermands the special case by checking
> (bolp) and then doing the opposite adjustment.
>
> However, there's one more case to consider: when point starts out
> right after a page delimiter (i.e. the very first positon on a page),
> the page--what-page while loop will leave the final point there too,
> and then count-lines will return 0. The line number should be 1, so
> an adjustment is needed there too.
>
> The updated test is the same as the previous round, and they still
> pass with the new patch.
>
> > > + "Return a list of the page number of point, and the line number
> > > +within that page."
> >
> > Our convention is to have the first line of a doc string be a single
> > complete sentence.
>
> Fixed by moving info to a second line, or rephrasing to one line.
Thanks, installed on the master branch, and closing the bug.
--- End Message ---