bug#20587: 24.1 forward-line docs inconsistent/surprising return value

[Eli Zaretskii]

> Date: Sat, 16 May 2015 16:28:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20587@debbugs.gnu.org
> 
> > It may be that the behaviour is so ancient that it cannot be altered 
> > without breaking things: I wouldn't push for the behaviour change in
> > that case. But I think the special case should be more clearly flagged
> > and stated.
> 
> If we agree about the behavior, I can change the doc string.  That's
> easy enough.

Actually, now that I read the doc string in its entirety, it seems to
say all that already:

  Move N lines forward (backward if N is negative).
  Precisely, if point is on line I, move to the start of line I + N
  ("start of line" in the logical order).
  If there isn't room, go as far as possible (no error).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Returns the count of lines left to move.  If moving forward,
  that is N - number of lines moved; if backward, N + number moved.
  With positive N, a non-empty line at the end counts as one line
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  successfully moved (for the return value).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If those 2 sentences don't describe the situation with a buffer that
ends in a line without a newline, then what is missing or unclear
here, in your opinion?

So are you saying that the only documentation that needs to be
clarified is the ELisp manual?