GNU bug report logs - #8667
24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Fri, 13 May 2011 00:47:02 UTC

Severity: normal

Merged with 8670

Found in version 24.0.50

Done: "Drew Adams" <drew.adams <at> oracle.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 8667 <at> debbugs.gnu.org
Subject: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 11:11:07 -0300
> (Dunno why some people insist on using `(if (and...) singleton)'.

Probably because those people find it better communicates the intent.

> And it seems that `forward-comment' is otherwise buggy, in that it moves only
> over whitespace when point is within a comment.

Not only over whitespace: also over a nested comment.
What would you want it to do instead?  Jump to the end of the comment?
Kind of like an `up-comment'?

The forward-<thingy> functions all share the following property AFAIK:
when called with a positive argument with point *before* some
<thingies>, they will skip over that many <thingies> and when called
with a negative argument with point *after* some <thingies> they will
skip over that many <thingies>.

E.g. just like forward-comment, forward-sexp from within a sexp will not
skip to the end of that sexp.  And just like forward-sexp,
forward-comment called in front of a nested comment will jump over that
nested comment.

All calls with point elsewhere than before/after a <thingy> behave in
somewhat arbitrary ways which mostly depend on how the function is
implemented and what kind of structure <thingies> have (e.g. can they
nest?  Can we easily tell when we're in the middle of a <thingy>?).


        Stefan




This bug report was last modified 14 years and 62 days ago.

Previous Next


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