bug#21391: 24.5; `thing-at-point' returns error when called with arguments 'number t)

[Drew Adams]

> >>> Is there a need to pick symbols from a buffer as symbols?
> >>> Don't know. My use-case is editing and strings are the suitable
> >>> format.
> >> Of course there is.  And not just symbols, but numbers, lists...
> > Sorry for the confusion.  I was thinking of `list-at-point' etc.,
> > and not `thing-at-point', which always returns a string (or it
> > should, at least - see my previous msg).
> 
> AFAIU the symbol-at-point-as-symbol idea and thing-at-point are two
> different conceptions.
> 
> BTW can't see a use-case of form-at-point for know - while
> having some in mind ;)

A particular kind of thing at point is defined using function
`form-at-point' or by using the `thing-at-point' symbol property.
`form-at-point' is essentially a building block (helper).

This is different from what `thing-at-point', which returns
text (a string) that names or represents a thing at point of
a particular kind.

Examples of functions defined using `form-at-point' include
`symbol-at-point', which returns a symbol, not a symbol name
(string); `number-at-point', which returns a number, not a
numeral (string); and `list-at-point', which returns a list
(not a string representing a list).

In my library `thingatpt+.el' I define functions such as
`symbol-name-at-point', which returns a string naming the
symbol at point, and `non-nil-symbol-name-at-point', which
is the same but returns nil instead of the symbol name "nil",
if there is no symbol (including no symbol `nil') at point.
Using `-name-' as part of the function name helps make clear
that such functions return strings, not symbols.