Re: thing-at-point: inconsistent behaviour?

[Raffaele Ricciardi <rfflrccrd@gmail.com>]

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.