GNU bug report logs -
#21391
24.5; `thing-at-point' returns error when called with arguments 'number t
Previous Next
Reported by: Tino Calancha <f92capac <at> gmail.com>
Date: Tue, 1 Sep 2015 01:57:01 UTC
Severity: minor
Found in version 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #85 received at submit <at> debbugs.gnu.org (full text, mbox):
On 07.11.2016 18:37, Drew Adams wrote:
>>> `thing-at-point' should always return a string.
>> Indeed. Which would require some normalization WRT number-at-point
>> etc.
> `number-at-point' uses `form-at-point'. It returns a number (or nil),
> not a numeral (string). It satisfies `numberp', not `stringp'.
>
> What normalization do you have in mind?
Still think detecting buffer-substrings according to THING and returning
them if found at point --nil otherwise-- is most straightforward.
> (I have also `decimal-number-at-point' and `hex-number-at-point', FWIW.)
>
>>> `list-at-point', `form-at-point', etc. are a different
>>> story - they can return anything.
>> Interesting question. Maybe returns the symbol if found - nil
>> otherwise?
> That's what `symbol-at-point' does.
Unfortunately it does more - it might change the symbol-table. Expect a
passive, plain report instead.
> However, since `nil' is a
> symbol, `symbol-at-point' does not distinguish between finding
> that symbol and not finding any symbol at point.
>
> The others return a thing of the given type (or nil, if none).
>
> `list-at-point', like `symbol-at-point', does not distinguish
> between an empty list at point (buffer text "nil" or "()" or "( )"
> etc.) and no list at point. The doc for `list-at-point' should in
> fact say that it returns the _non-nil_ list at point, or nil if none.
>
> It should also return the list (quote (1 2)) when on '(1 2) (it's
> broken, IMO). (I also have a function `unquoted-list-at-point'.)
This bug report was last modified 4 years and 329 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.