GNU bug report logs - #13994
End of buffer error for forward-sexp

Previous Next

Full log

Message #17 received at 13994 <at> debbugs.gnu.org (full text, mbox):

From: "Aaron S. Hawley" <aaron.s.hawley <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13994 <at> debbugs.gnu.org
Subject: Re: bug#13994: End of buffer error for forward-sexp
Date: Wed, 24 Apr 2013 17:35:28 -0400

> 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?

What I'm finding in my small sample is that most code already has
ignore-errors or is finding the end or beginning of a buffer with a
different Emacs primitive.  In other words, no code changes!

> 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?

I wouldn't have sent a patch if I didn't think it should be the default.

> 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.

I don't believe my patch is changing that behavior.

> 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.

I'm pretty sure my patch doesn't take anything away from the user's
ability to entirely redefine forward-sexp by setting
forward-sexp-function.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.