RE: symbol-at-point

["Drew Adams" <drew.adams@oracle.com>]

> > Wouldn't it be more clean to write a separate (intern
> > SYMBOL-at-point) function, if someone wants to do that?
>
> I agree that symbol-at-point should return a string.
> When I fixed symbol-at-point to work in non-elisp major modes, I preserved
> this part of the behavior for no good reason.

No, it should not return a string. Changing that could mean changing code
that uses the result, for example, in a completion list. Even though Emacs
22 now accepts a list of strings in place of an alist as a completion list,
I think that change would be a bad idea.

It's better to leave `symbol-at-point' as is, returning a symbol, and have a
separate function, `symbol-name-at-point', which gives you the name. That is
the approach I took in the thingatpt.el patch I sent.

> But returning a symbol has the main disadvantage that you can't
> distinguish the case where point is not on a symbol (w.g. it's
> looking at a semi-colon) from the case where it's looking at
> the symbol "nil".

Right. In the patch that I sent, these issues are addressed (for Lisp
symbols). Separate `lisp-symbol-name-*' functions return the symbol name, or
"" if there is no such symbol, whereas `list-symbol-*' returns the symbol
itself (possibly nil) or nil if thre is no such symbol.

I also included functions to return the name of a non-nil symbol or "", if
there is none: `non-nil-lisp-symbol-name-nearest-point',
`non-nil-lisp-symbol-name-at-point'.

For the symbol itself (not its name) at point, there is obviously no need
for a non-nil version. However, there is a function
`non-nil-symbol-nearest-point', which returns the nearest non-nil symbol, or
nil if there is none. ("there is none" means there is none within the
user-specifiable limits that define "nearness".)