[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comme

From: Drew Adams
Subject: 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]