thing-at-point: inconsistent behaviour?

thing-at-point: inconsistent behaviour?

[Raffaele Ricciardi]

Hello there,

the documentation of `thing-at-point' states that such function returns "the
thing around or next to point".  This is not the case with either 
(thing-at-point
'symbol) or (thing-at-point 'sexp), for they both may return the thing 
before
point.  Try it with the following snippet (! symbolizes the point):

A!
(A)!

On the contrary, (bounds-of-thing-at-point 'list) returns nil as 
expected in this
snippet:

(A)!

Is this inconsistent behaviour or am I missing something?

Tested on GNU Emacs 24.1 started with "emacs -Q".

Thank you.

Re: thing-at-point: inconsistent behaviour?

[Barry Margolin]

In article <a926tjFeslU1@mid.individual.net>,
 Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:

> Hello there,
> 
> the documentation of `thing-at-point' states that such function returns "the
> thing around or next to point".  This is not the case with either 
> (thing-at-point
> 'symbol) or (thing-at-point 'sexp), for they both may return the thing 
> before
> point.  Try it with the following snippet (! symbolizes the point):

Doesn't "next to" include both immediately before and immediately after?

> 
> A!
> (A)!
> 
> On the contrary, (bounds-of-thing-at-point 'list) returns nil as 
> expected in this
> snippet:
> 
> (A)!
> 
> Is this inconsistent behaviour or am I missing something?
> 
> Tested on GNU Emacs 24.1 started with "emacs -Q".
> 
> Thank you.

I think this is a problem with the thing-at-point handler for 'list.  
It's doing some weird stuff, that I think is intended to distinguide 
lists from sexps.  I guess it's only supposed to match lists embedded in 
code, not the list that represents a toplevel expression.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

RE: thing-at-point: inconsistent behaviour?

[Drew Adams]

FWIW, you might try `thingatpt+.el'.

I think you'll find that it provides better support for sexps and lists, among
other things.  If it helps, fine; if not, move on.

http://www.emacswiki.org/emacs-en/thingatpt%2b.el

http://emacswiki.org/emacs/ThingAtPoint#toc4

Re: thing-at-point: inconsistent behaviour?

[Raffaele Ricciardi]

On 08/15/2012 07:34 PM, Barry Margolin wrote:
 > In article <a926tjFeslU1@mid.individual.net>,
 >   Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
 >
 >> Hello there,
 >>
 >> the documentation of `thing-at-point' states that such function 
returns "the
 >> thing around or next to point".  This is not the case with either
 >> (thing-at-point
 >> 'symbol) or (thing-at-point 'sexp), for they both may return the thing
 >> before
 >> point.  Try it with the following snippet (! symbolizes the point):
 >
 > Doesn't "next to" include both immediately before and immediately after?

I stand corrected after having consulted a dictionary.  Then it is
(thing-at-point 'list) that is misbehaving.

 >
 >>
 >> A!
 >> (A)!
 >>
 >> On the contrary, (bounds-of-thing-at-point 'list) returns nil as
 >> expected in this
 >> snippet:
 >>
 >> (A)!
 >>
 >> Is this inconsistent behaviour or am I missing something?
 >>
 >> Tested on GNU Emacs 24.1 started with "emacs -Q".
 >>
 >> Thank you.
 >
 > I think this is a problem with the thing-at-point handler for 'list.
 > It's doing some weird stuff, that I think is intended to distinguide
 > lists from sexps.

Aren't lists sexps as well?

Re: thing-at-point: inconsistent behaviour?

[Andreas Röhler]

Am 15.08.2012 21:00, schrieb Raffaele Ricciardi:
> On 08/15/2012 07:34 PM, Barry Margolin wrote:
>  > In article <a926tjFeslU1@mid.individual.net>,
>  >   Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
>  >
>  >> Hello there,
>  >>
>  >> the documentation of `thing-at-point' states that such function returns "the
>  >> thing around or next to point".  This is not the case with either
>  >> (thing-at-point
>  >> 'symbol) or (thing-at-point 'sexp), for they both may return the thing
>  >> before
>  >> point.  Try it with the following snippet (! symbolizes the point):
>  >
>  > Doesn't "next to" include both immediately before and immediately after?
>
> I stand corrected after having consulted a dictionary.  Then it is
> (thing-at-point 'list) that is misbehaving.
>


hmm, IMHO you was right. Here is the code

(defun symbol-at-point ()
   "Return the symbol at point, or nil if none is found."
   (let ((thing (thing-at-point 'symbol)))
     (if thing (intern thing))))

last line don't return the thing as delivered by thing-at-point but the result of (intern thing)

that way breaking consistency.

BTW built a library at top of thing-at-point rationale, which aims to avoid that

https://launchpad.net/s-x-emacs-werkstatt/trunk/1.3/+download/S-X-Emacs-Werkstatt-1.3.tar.gz



>  >
>  >>
>  >> A!
>  >> (A)!
>  >>
>  >> On the contrary, (bounds-of-thing-at-point 'list) returns nil as
>  >> expected in this
>  >> snippet:
>  >>
>  >> (A)!
>  >>
>  >> Is this inconsistent behaviour or am I missing something?
>  >>
>  >> Tested on GNU Emacs 24.1 started with "emacs -Q".
>  >>
>  >> Thank you.
>  >
>  > I think this is a problem with the thing-at-point handler for 'list.
>  > It's doing some weird stuff, that I think is intended to distinguide
>  > lists from sexps.
>
> Aren't lists sexps as well?
>

Re: thing-at-point: inconsistent behaviour?

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

In article <mailman.7107.1345117968.855.help-gnu-emacs@gnu.org>,
 Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Am 15.08.2012 21:00, schrieb Raffaele Ricciardi:
> > On 08/15/2012 07:34 PM, Barry Margolin wrote:
> >  > In article <a926tjFeslU1@mid.individual.net>,
> >  >   Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
> >  >
> >  >> Hello there,
> >  >>
> >  >> the documentation of `thing-at-point' states that such function returns 
> >  >> "the
> >  >> thing around or next to point".  This is not the case with either
> >  >> (thing-at-point
> >  >> 'symbol) or (thing-at-point 'sexp), for they both may return the thing
> >  >> before
> >  >> point.  Try it with the following snippet (! symbolizes the point):
> >  >
> >  > Doesn't "next to" include both immediately before and immediately after?
> >
> > I stand corrected after having consulted a dictionary.  Then it is
> > (thing-at-point 'list) that is misbehaving.
> >
> 
> 
> hmm, IMHO you was right. Here is the code
> 
> (defun symbol-at-point ()
>    "Return the symbol at point, or nil if none is found."
>    (let ((thing (thing-at-point 'symbol)))
>      (if thing (intern thing))))
> 
> last line don't return the thing as delivered by thing-at-point but the 
> result of (intern thing)
> 
> that way breaking consistency.

That function has nothing to do with the problem he's reporting. It's 
just an extra utility function that makes use of thing-at-point to 
return something that may be useful in certain situations.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: thing-at-point: inconsistent behaviour?

[Andreas Röhler]

Am 16.08.2012 17:48, schrieb Barry Margolin:
> In article <mailman.7107.1345117968.855.help-gnu-emacs@gnu.org>,
>   Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>
>> Am 15.08.2012 21:00, schrieb Raffaele Ricciardi:
>>> On 08/15/2012 07:34 PM, Barry Margolin wrote:
>>>   > In article <a926tjFeslU1@mid.individual.net>,
>>>   >   Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
>>>   >
>>>   >> Hello there,
>>>   >>
>>>   >> the documentation of `thing-at-point' states that such function returns
>>>   >> "the
>>>   >> thing around or next to point".  This is not the case with either
>>>   >> (thing-at-point
>>>   >> 'symbol) or (thing-at-point 'sexp), for they both may return the thing
>>>   >> before
>>>   >> point.  Try it with the following snippet (! symbolizes the point):
>>>   >
>>>   > Doesn't "next to" include both immediately before and immediately after?
>>>
>>> I stand corrected after having consulted a dictionary.  Then it is
>>> (thing-at-point 'list) that is misbehaving.
>>>
>>
>>
>> hmm, IMHO you was right. Here is the code
>>
>> (defun symbol-at-point ()
>>     "Return the symbol at point, or nil if none is found."
>>     (let ((thing (thing-at-point 'symbol)))
>>       (if thing (intern thing))))
>>
>> last line don't return the thing as delivered by thing-at-point but the
>> result of (intern thing)
>>
>> that way breaking consistency.
>
> That function has nothing to do with the problem he's reporting. It's
> just an extra utility function that makes use of thing-at-point to
> return something that may be useful in certain situations.
>

okay, as it happens it's for years in my mind: that symbol-at-point breaks consistency.

Another approach to give the reasons:

IMO basically two ways of returns are feasible by such a thing-at-point library

- deliver objects from editing perspective, i.e as buffer-substrings
- deliver objects for use in programs

The latter seems the focus so far.

Not to expect is changing the computers internal state already when picking an object by thing-at-point.
That's what is done by "intern" however.

Re: thing-at-point: inconsistent behaviour?

[Raffaele Ricciardi]

On 08/16/2012 05:24 PM, Andreas Röhler wrote:
 > Am 16.08.2012 17:48, schrieb Barry Margolin:
 >> In article <mailman.7107.1345117968.855.help-gnu-emacs@gnu.org>,
 >>   Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
 >>
 >>> Am 15.08.2012 21:00, schrieb Raffaele Ricciardi:
 >>>> On 08/15/2012 07:34 PM, Barry Margolin wrote:
 >>>>   > In article <a926tjFeslU1@mid.individual.net>,
 >>>>   >   Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:
 >>>>   >
 >>>>   >> Hello there,
 >>>>   >>
 >>>>   >> the documentation of `thing-at-point' states that such function
 >>>> returns
 >>>>   >> "the
 >>>>   >> thing around or next to point".  This is not the case with either
 >>>>   >> (thing-at-point
 >>>>   >> 'symbol) or (thing-at-point 'sexp), for they both may return
 >>>> the thing
 >>>>   >> before
 >>>>   >> point.  Try it with the following snippet (! symbolizes the
 >>>> point):
 >>>>   >
 >>>>   > Doesn't "next to" include both immediately before and
 >>>> immediately after?
 >>>>
 >>>> I stand corrected after having consulted a dictionary.  Then it is
 >>>> (thing-at-point 'list) that is misbehaving.
 >>>>
 >>>
 >>>
 >>> hmm, IMHO you was right. Here is the code
 >>>
 >>> (defun symbol-at-point ()
 >>>     "Return the symbol at point, or nil if none is found."
 >>>     (let ((thing (thing-at-point 'symbol)))
 >>>       (if thing (intern thing))))
 >>>
 >>> last line don't return the thing as delivered by thing-at-point but the
 >>> result of (intern thing)
 >>>
 >>> that way breaking consistency.
 >>
 >> That function has nothing to do with the problem he's reporting. It's
 >> just an extra utility function that makes use of thing-at-point to
 >> return something that may be useful in certain situations.
 >>
 >
 > okay, as it happens it's for years in my mind: that symbol-at-point
 > breaks consistency.
 >
 > Another approach to give the reasons:
 >
 > IMO basically two ways of returns are feasible by such a thing-at-point
 > library
 >
 > - deliver objects from editing perspective, i.e as buffer-substrings
 > - deliver objects for use in programs

When you are looking for a buffer substring, you call
`bounds-of-thing-at-point'; when you are looking for a string result, 
you call
`thing-at-point'; when you want the result as a sexp, you call the 
specialized
function.

 > Not to expect is changing the computers internal state already when
 > picking an object by thing-at-point.
 > That's what is done by "intern" however.

Indeed this is an undesirable side effect of `symbol-at-point' calling
`intern'.  Could `intern' be replaced with `make-symbol'?

Re: thing-at-point: inconsistent behaviour?

[Barry Margolin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

In article <a94o01FiegU1@mid.individual.net>,
 Raffaele Ricciardi <rfflrccrd@gmail.com> wrote:

> On 08/16/2012 05:24 PM, Andreas Röhler wrote:
>  > Not to expect is changing the computers internal state already when
>  > picking an object by thing-at-point.
>  > That's what is done by "intern" however.
> 
> Indeed this is an undesirable side effect of `symbol-at-point' calling
> `intern'.  Could `intern' be replaced with `make-symbol'?

Most applications that use symbols need interned symbols.  If you're 
doing something that wants an uninterned symbol, call (make-symbol 
(thing-at-point 'symbol)).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

RE: thing-at-point: inconsistent behaviour?

[Drew Adams]

> When you are looking for a buffer substring, you call
> `bounds-of-thing-at-point'; when you are looking for a string
> result, you call `thing-at-point'; when you want the result
> as a sexp, you call the specialized function.

There is even another complication/confusion.  "Symbol" in Emacs can refer to
two different things, especially as regards text that might represent a name.

* It can refer to a string of chars that have symbol syntax (or symbol-or-word
syntax) in a given mode - any mode, not just Lisp.

* It can refer to a Lisp symbol, i.e., a specific kind of Lisp object (with the
possibility of a non-nil `symbol-value' and `symbol-function, for instance).

IMO, most Elisp programs use thing-at-point functions to grab a string
representing the name of something or representing a sexp or other object (URL,
file name, etc.).

In the case of a symbol, IMO most programs really want/need to grab a symbol
_name_, often for use as the default value in an interactive spec.  Most do not
really want/need a Lisp symbol.  And even when they do, they can call `intern'
or `intern-soft' or `make-symbol' themselves.

In `thingatpt+.el' there are separate functions that return a Lisp symbol (i.e.,
interned in the standard `obarray'), and there are other functions that return a
symbol name.  The symbol-name functions are used more often, IMO.

Symbols:

 `symbol-at-point'
 `symbol-nearest-point'
 `non-nil-symbol-nearest-point' 

Symbol names:

 `non-nil-symbol-name-at-point'
 `symbol-name-nearest-point'
 `non-nil-symbol-name-nearest-point'
 `region-or-non-nil-symbol-name-nearest-point' 

(There are also functions that return the symbol or symbol name plus its bounds
in the buffer, and so on.)

Re: thing-at-point: inconsistent behaviour?

[Barry Margolin]

In article <mailman.7128.1345164390.855.help-gnu-emacs@gnu.org>,
 "Drew Adams" <drew.adams@oracle.com> wrote:

> > When you are looking for a buffer substring, you call
> > `bounds-of-thing-at-point'; when you are looking for a string
> > result, you call `thing-at-point'; when you want the result
> > as a sexp, you call the specialized function.
> 
> There is even another complication/confusion.  "Symbol" in Emacs can refer to
> two different things, especially as regards text that might represent a name.
> 
> * It can refer to a string of chars that have symbol syntax (or 
> symbol-or-word
> syntax) in a given mode - any mode, not just Lisp.
> 
> * It can refer to a Lisp symbol, i.e., a specific kind of Lisp object (with 
> the
> possibility of a non-nil `symbol-value' and `symbol-function, for instance).
> 
> IMO, most Elisp programs use thing-at-point functions to grab a string
> representing the name of something or representing a sexp or other object 
> (URL,
> file name, etc.).
> 
> In the case of a symbol, IMO most programs really want/need to grab a symbol
> _name_, often for use as the default value in an interactive spec.  Most do 
> not
> really want/need a Lisp symbol.  And even when they do, they can call 
> `intern'
> or `intern-soft' or `make-symbol' themselves.

Then they should call (thing-at-point 'symbol), not (symbol-at-point).  
It seems like this tangent is because someone thought that the latter 
should just be a shorthand for the former, but they do different things 
and are intended for different situations.  If symbol-at-point doesn't 
do what you want (e.g. it interns things when you would prefer it 
didn't), don't use it. No one's forcing you to.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

RE: thing-at-point: inconsistent behaviour?

[Drew Adams]

> > In the case of a symbol, IMO most programs really want/need 
> > to grab a symbol _name_, often for use as the default value
> > in an interactive spec.  Most do not really want/need a Lisp
> > symbol.  And even when they do, they can call `intern'
> > or `intern-soft' or `make-symbol' themselves.
> 
> Then they should call (thing-at-point 'symbol), not 
> (symbol-at-point).

Yes.

On the other hand, for many such use cases it is not very useful to obtain a
value of `nil' (a symbol, not a string) when there is no symbol name at point
(not even "nil").  Function `non-nil-symbol-name-at-point' returns "" in that
case.  It is, in effect, (or (thing-at-point 'symbol) "").
 
> It seems like this tangent is because someone thought that the
> latter should just be a shorthand for the former, but they do 
> different things and are intended for different situations.  If 
> symbol-at-point doesn't do what you want (e.g. it interns things
> when you would prefer it didn't), don't use it. No one's forcing
> you to.

Exactly.  And not just "someone" - such confusion does not seem that rare.

You might have come to understand that (thing-at-point 'symbol) returns a
string, and you correctly distinguish it from what `symbol-at-point' does, but
it is easy for others not to get this.

Especially since `thing-at-point' does NOT always return a string - it returns a
list for (thing-at-point 'list), for instance.  There is nothing in the name,
i.e., on the surface of it, that tells you that (thing-at-point 'symbol) returns
either a symbol name or the symbol `nil'.  It looks every bit like it might
return the thing at point that is a symbol.

This confusion wrt symbols is why it is helpful to provide a function that has
`symbol-name' and not just `symbol' in its name, the former doing, in effect,
what (or (thing-at-point 'symbol) "") does.

BTW, I don't think most use cases really care whether or not the name has been
interned.  What is more important usually is what kind of value is returned: a
symbol or a string (symbol name).

The other thing that can be important for some use cases is to distinguish the
absence of any symbol name at point from the presence of the symbol name "nil"
at point.  When picking up a symbol name to serve as a completion candidate for
some input, it is often the case that "nil" is not appropriate.

FWIW, this 2007 Emacs Devel thread discusses exactly what is being discussed in
the present thread, and a bit more:

http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01520.html

Re: thing-at-point: inconsistent behaviour?

[Raffaele Ricciardi]

On 08/17/2012 05:38 AM, Drew Adams wrote:
 >>> In the case of a symbol, IMO most programs really want/need
 >>> to grab a symbol _name_, often for use as the default value
 >>> in an interactive spec.  Most do not really want/need a Lisp
 >>> symbol.  And even when they do, they can call `intern'
 >>> or `intern-soft' or `make-symbol' themselves.
 >>
 >> Then they should call (thing-at-point 'symbol), not
 >> (symbol-at-point).
 >
 > Yes.
 >
 > On the other hand, for many such use cases it is not very useful to 
obtain a
 > value of `nil' (a symbol, not a string) when there is no symbol name 
at point
 > (not even "nil").  Function `non-nil-symbol-name-at-point' returns "" 
in that
 > case.  It is, in effect, (or (thing-at-point 'symbol) "").
 >
 >> It seems like this tangent is because someone thought that the
 >> latter should just be a shorthand for the former, but they do
 >> different things and are intended for different situations.  If
 >> symbol-at-point doesn't do what you want (e.g. it interns things
 >> when you would prefer it didn't), don't use it. No one's forcing
 >> you to.
 >
 > Exactly.  And not just "someone" - such confusion does not seem that 
rare.
 >
 > You might have come to understand that (thing-at-point 'symbol) returns a
 > string, and you correctly distinguish it from what `symbol-at-point' 
does, but
 > it is easy for others not to get this.
 >
 >
 > This confusion wrt symbols is why it is helpful to provide a function 
that has
 > `symbol-name' and not just `symbol' in its name, the former doing, in 
effect,
 > what (or (thing-at-point 'symbol) "") does.
 >
 > BTW, I don't think most use cases really care whether or not the name 
has been
 > interned.  What is more important usually is what kind of value is 
returned: a
 > symbol or a string (symbol name).
 >
 > The other thing that can be important for some use cases is to 
distinguish the
 > absence of any symbol name at point from the presence of the symbol 
name "nil"
 > at point.  When picking up a symbol name to serve as a completion 
candidate for
 > some input, it is often the case that "nil" is not appropriate.
 >
 > FWIW, this 2007 Emacs Devel thread discusses exactly what is being 
discussed in
 > the present thread, and a bit more:
 >
 > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01520.html
 >
 >

Indeed there is ambiguity in the naming of `symbol-at-point', for as 
Drew has
pointed out in another reply of his, `symbol' is a context-sensitive term,
e.g. an Emacs Lisp symbol or a symbol according to the active syntax 
table.  As
such, users could oversee that `symbol-at-point' works only in the 
context of
Emacs Lisp programs.  As a counterexample, the specificity of 
`list-at-point'
and 'sexp-at-point' is obvious.  Maybe `symbol-at-point' could document 
that it
returns the interned Emacs Lisp symbol at point, thus avoiding any 
confusion?
Also, the documentation string could redirect to `thing-at-point' - or 
to a new
`symbol-name-at-point' function - users who want to distinguish between no
symbol and `nil'.

 > Especially since `thing-at-point' does NOT always return a string -
 > it returns a
 > list for (thing-at-point 'list), for instance.  There is nothing in 
the name,
 > i.e., on the surface of it, that tells you that (thing-at-point 
'symbol) returns
 > either a symbol name or the symbol `nil'.  It looks every bit like it 
might
 > return the thing at point that is a symbol.

On my GNU Emacs 24.1, `thing-at-point' always returns a (propertized) 
string,
including when used with 'list.

RE: thing-at-point: inconsistent behaviour?

[Drew Adams]

>  > Especially since `thing-at-point' does NOT always return a string -
>  > it returns a list for (thing-at-point 'list), for instance.
> 
> On my GNU Emacs 24.1, `thing-at-point' always returns a (propertized) 
> string, including when used with 'list.

Yes, my bad about that one.  I think my point there was (or should have been)
that vanilla `thing-at-point' can return anything at all.  You cannot depend on
it to return a string or nil.

The version in `thingatpt+.el' ensures that the function returns a string or
nil, but the vanilla version does not.  This is because the vanilla version just
returns whatever the function that is the value of (get THING 'thing-at-point)
returns (if that property is non-nil).  It does not convert that (if non-nil) to
a string.

Since it is user-developers who put that property on THING symbols, they can use
whatever function they like, returning anything they like.

It is unfortunate that the terminology and function names suggest that any kind
of Lisp object (any THING) is returned by `thing-at-point', whereas its mission,
according to the doc (but not actually enforced) is to return only a string (or
nil).  It is really about giving you a buffer substring that _represents_ a Lisp
object (e.g. a list or a symbol).

It is all the more confusing because `thingatpt.el' also defines other
functions, such as `sexp-at-point', `symbol-at-point', `number-at-point', and
`list-at-point', which _do_ return Lisp objects.

It is further confusing because the function used to do that is `form-at-point'.
The Elisp manual gives "form" as "a Lisp object that is intended for
evaluation."

So user-developers should think to use `form-at-point' and not `thing-at-point'
if they want to return a Lisp object.  The difference is that `form-at-point'
reads the string returned by `thing-at-point', to obtain a Lisp object.

Function `thing-at-point' is about source-code representations of Lisp things.
Function `form-at-point' is about Lisp things.

And because it is so easy to just put a function on a symbol as property
`thing-at-point', users can wind up with perfectly workable calls to
`thing-at-point' which do just what they want but which do not, as the doc says,
return a string (or nil).

There are thus a few things to keep straight, starting with (1) the difference
between (thing-at-point 'symbol), which returns a symbol name and not a symbol
(likewise, for other THINGs - lists etc.), and ending with (2) the difference
between `thing-at-point' and `form-at-point' and (3) the caveat that
`thing-at-point' (a) is not intended to do what its name suggests (return a Lisp
THING) and (b) is not guaranteed to do what its doc says (return a string
representing a Lisp THING, or nil).