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

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

> The problem is that there is no `beginning-op' or `end-op' and all of
> the calls to `forward-thing' (with 1 and -1) do not move point at all,
> and return nil.  So the code falls through to the end:
>  
> (let ((end (point))
>       (real-beg
>        (progn
>         (funcall
>          (or (get thing 'beginning-op)
>              (lambda () (forward-thing thing -1))))
>         (point))))
>   ;; real-beg = end = (point).  Result is (cons 3061 . 3061).
>   (if (and real-beg end (<= real-beg orig) (<= orig end))
>       (cons real-beg end)))
> 
> `bounds-of-thing-at-point' should foresee such a case (that 
> `forward-THING' does nothing).  IOW, it should of course be
>  fixed for this problem.

This should be all that's needed, if it wasn't obvious:

- (if (and beg real-end (<= beg orig) (<= orig real-end))
-     (cons beg real-end))

+ (and beg real-end (<= beg orig) (<= orig real-end)
+      (/= beg read-end)
+      (cons beg real-end))

and

- (if (and real-beg end (<= real-beg orig) (<= orig end))
-     (cons real-beg end)))

+ (and real-beg end (<= real-beg orig) (<= orig end)
+      (/= real-beg end)
+      (cons real-beg end))

(Dunno why some people insist on using `(if (and...) singleton)'.  It gets in
the way of readability and just represents extra noise.  Binary `if' is
generally an impediment to readability and communicating intention.)

> But it sounds like `forward-comment' should also be fixed so 
> that it acts like other `forward-THING' functions, and not
> just be a no-op when outside a comment.

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

E.g.:
;; Some comment with some     whitespace somewhere.

Put point before any of the whitespace and (forward-comment 1) moves to the end
of the whitespace.  Put point after any of the whitespace and (forward-comment
-1) moves to the beginning of that whitespace.  And in these cases swapping 1
and -1 produces a no-op.

The only time `forward-comment' actually moves over a whole (Lisp) comment is
when point is before `;'.  And even then, if point is between the two `;' above,
then (forward-comment -1) is a no-op.

`forward-comment' should behave the way other `forward-THING' functions behave.
It should do what we expect of a `forward-*' function.

Yes, I have read the `forward-comment' doc string.  If it really needs to behave
this way then it should have a different name.  That is, after fixing the bugged
behavior, if we still need a function that does what `forward-comment' does now,
then it needs a different name.

No, it's not too late to change, even if renaming would be bothersome.  The way
it is now breaks `thing-at-point' functions, and they should work regardless of
the `forward-*' functions.  Thing-at-point depends on this naming convention.