bug#13994: End of buffer error for forward-sexp

["Drew Adams" <drew.adams@oracle.com>]

> I by no means use all of Emacs, but haven't run into an issue yet with
> my patch.  I use Emacs with t-d-o-e on.

Pretty small sample.

> Do you have an example of code that you've seen "needs the current
> behavior" at the beginning or end of the buffer....
> 
> So far, I've looked at these functions in Emacs to see if 
> they still work.
> 
> end-of-sexp
> beginning-of-sexp
> thing-at-point-bounds-of-list-at-point
> sort-numeric-fields
> transpose-sexps
> blink-matching-open
> diary-list-sexp-entries
> diary-mark-sexp-entries
> comint-extract-string

Pretty small sample.  There must be thousands of uses of `forward-sexp' in
existing Emacs-Lisp code out there.  How many of them depend (intentionally or
not) on `forward-sexp' returning nil for premature `eobp'?  Who knows.

Now everytime some code does (when (looking-at "\"") (forward-sexp 1)) or
whatever it will need to be fixed to wrap it in `ignore-errors' or otherwise
treat the `eobp' case?

Doesn't sound like a sound approach at this point.
Might have been a reasonable suggestion 30 years ago.

What's the point?  If you have some code that needs to raise an error when
`forward-sexp' reaches eob, that's easy enough to do, no?

Not to mention that the code for `forward-sexp' explicitly takes point to eob
when `scan-sexps' returns nil.  IOW, that behavior is presumably by design.

And not to mention that it calls `forward-sexp-function', if non-nil, to do
everything, in which case (depending on where you would place your call to
`error') you might be changing the meaning/behavior for its code as well, if it
reaches eob.