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.