Re: Patch for beginning-of-visual-line and end-of-visual-line

[Justin Burkett <justin@burkett.cc>]

[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]

> So I think this behavior is correct, perhaps we should describe this
> special case in the doc string.  This function must end up at the
> beginning of a visual line, and in your case there's only one such
> place.  Note that (beginning-of-visual-line 1) and
> (beginning-of-visual-line) all end up in the same place in this case.


That's fine with me. While we're at it, move-beginning-of-line has the same
inconsistency in the docstring. Arguably it's not that special of a case.
With 50 lines in a buffer that doesn't end in a newline,
(beginning-of-visual-line 99) does not end up at the end of the buffer as
suggested by the docstring. In other words, it's the result of a buffer not
ending in a newline, not that there is only one line in the buffer.

Also, it would be nice to specify what the return value of these functions
is if the docstring will change.

Thanks,
Justin


On Sat, Aug 12, 2017 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Justin Burkett <justin@burkett.cc>
> > Date: Fri, 11 Aug 2017 17:10:23 -0400
> > Cc: emacs-devel@gnu.org
> >
> > $ emacs -Q
> > C-x b *test* RET
> > asdf
> > M-: (beginning-of-visual-line 2)
> >
> > point ends up at the beginning of the buffer for me. Note this doesn't
> > happen with a final newline in the buffer.
>
> Ah, that was the missing bit.
>
> So I think this behavior is correct, perhaps we should describe this
> special case in the doc string.  This function must end up at the
> beginning of a visual line, and in your case there's only one such
> place.  Note that (beginning-of-visual-line 1) and
> (beginning-of-visual-line) all end up in the same place in this case.
>

[-- Attachment #2: Type: text/html, Size: 2378 bytes --]