--- Begin Message ---
|
Subject: |
24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment' |
|
Date: |
Thu, 12 May 2011 17:46:33 -0700 |
emacs -Q
Put point at position 3061 in file thingatpt.el (i.e., just before the
`a' of `condition-case').
M-: (bounds-of-thing-at-point 'comment)
returns (3061 . 3061), which represents an empty thing, "".
This happens at most positions, probably all positions outside a comment.
The code should handle this kind of case correctly (in other respects it
seems to work OK for comments).
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.
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.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
of 2011-05-10 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#8667: 24.0.50; `bounds-of-thing-at-point' returns (N . N) for `comment' |
|
Date: |
Fri, 13 May 2011 14:05:06 -0300 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Installed a patch along the lines of what you suggested.
>> 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)))))
The current behavior is clearly intentional (the (skip-chars-backward "
\t") shows that the function wants to treat newlines as
not-just-whitespace). So I'd rather not change it.
Stefan
--- End Message ---