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

Previous Next

Full log

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 8667 <at> debbugs.gnu.org
Subject: RE: bug#8667: 24.0.50;
	`bounds-of-thing-at-point' returns (N . N) for `comment'
Date: Fri, 13 May 2011 08:49:27 -0700

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

You're right, and I was aware of that.  While dealing with the
`bounds-of-thing-at-point' bug I mistakenly got the impression that
`forward-char' was also misbehaving.

Let's please fix `bounds-of-thing-at-point', though.  The fix is trivial.  It's
OK for `b-o-t-a-p' to return a purely whitespace thing (`whitespace' is even a
proper thing), but it's not OK for it to return an empty thing (""), IMO.

--

BTW (do I need to create a separate bug report for this?), I think
`forward-whitespace' is incorrect: \n should be \n+, like this:

(defun forward-whitespace (arg)
  (interactive "p")
  (if (natnump arg)
      (re-search-forward "[ \t]+\\|\n+" nil 'move arg)
    (while (< arg 0)
      (if (re-search-backward "[ \t]+\\|\n+" nil 'move)
	  (or (eq (char-after (match-beginning 0)) 10)
	      (skip-chars-backward " \t")))
      (setq arg (1+ arg)))))

Try `(bounds-of-thing-at-point 'whitespace)' at various places, in particular at
the end of a line followed by an empty line.  The current definition does not
consider contiguous whitespace from newlines to be part of the same whitespace
thing - it treats \n as separating whitespace things.

Dunno whether that was the intention (why?).  Without any indication of the
reason/intention (no doc string), I'd say that any sequence of contiguous
whitespace, including newlines, should form a single whitespace thing.

Can we also please add doc strings to functions such as `forward-whitespace'?
They are missing, generally, in thingatpt.el.

Previous Next

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