RE: symbol-at-point

[Drew Adams]

> >> > 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.
>
> I have no idea if code might break or not, but I'd assume that some amount
> of code would break, of course (your completion list example sounds highly
> unconvincing (lists of symbols have never worked any better than lists of
> strings), but I don't need any example to be convinced anyway).

I wasn't just contrasting strings with symbols. I meant a list of strings vs
an alist with string keys or an obarray of symbols. That's why I said a
"list of strings in place of an alist". Emacs 22 accepts a list of strings
as TABLE arg to `completing-read': ("foo" "bar"). Previously, you had to
pass an alist (("foo") ("bar")) or an obarray.

My point was that Emacs now accepts a list of strings, which might prevent
some code from breaking due to the change you propose, but I still think
that changing the return type of `symbol-at-point' would be a bad idea. Use
a new `symbol-name-at-point' function for that, instead.

> > 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.
>
> Sounds good to me.  Tho I guess that (thing-at-point 'symbol),
> which already works right now, isn't that bad either.
> But I do think we should discourage the use of symbol-at-point (i.e. mark
> it obsolete).

I don't think we should deprecate it, but I don't feel strongly about that.
I'm not persuaded that deprecating it would serve any purpose. I don't see
`symbol-at-point' as a bad thing at all. It's been around almost since Day
1, and it hasn't seemed to hurt anyone. My main complaint about it is that
it is too limited, not looking beyond the exact cursor position.

Wrt (thing-at-point 'symbol) vs (symbol-at-point): Sure, they do the same
thing. But some (most?) uses of such a function would be as a variable value
or as an arg to another function. Such a function naturally lends itself to
use in picking up a default value from text in the current buffer - that was
why `symbol-at-point' was created in the first place, AFAIK.

For that use, without `symbol-at-point' (or something similar), you would
need to use (lambda () (thing-at-point 'symbol)). Nothing wrong with that,
but I see nothing wrong either with keeping (without deprecating)
`symbol-at-point'.

By your argument, we should also deprecate `word-at-point',
`sentence-at-point', `sexp-at-point', `number-at-point', and
`list-at-point'. I don't see why we should do that. There is nothing wrong
with the simple convenience function
(defun sexp-at-point () (form-at-point 'sexp)).

> >> 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 see 0 need for such lisp-symbol-* functions:
> (with-syntax-table emacs-lisp-mode-syntax-table (thing-at-point 'symbol))
> works just fine and in most cases the with-syntax-table is not even needed
> because we know we're in an elisp buffer.

But if you want the name, not the symbol, then you also need to apply
`symbol-name'.

And `lisp-symbol-at-point' is what used to be `symbol-at-point', before you
"fixed" it by changing its meaning to not always return a Lisp symbol (not
use `emacs-lisp-mode-syntax-table'). That is, `lisp-symbol-at-point' just
provides the original meaning of `symbol-at-point', so, for instance, code
can use it to provide  help about an Emacs symbol that appears in a non-Lisp
buffer, such as *Help* or *info* or *Apropos*.

Without it, you would need (with-syntax-table emacs-lisp-mode-syntax-table
(symbol-name (thing-at-point 'symbol))) instead of just
(lisp-symbol-name-at-point).

Sure, there is no _need_ to define such functions; one can always write out
the code that implements them, each time. They are convenience functions.

A common use for such functions would be as the value of a
`<whatever>-default-input-fn' variable, to pick up text at or near the
cursor as the default value for a command that reads input. I do this, for
instance, for commands such as these:

 `query-replace', `find-dired', `flush-lines', `grep',
 `describe-variable', `where-is', `describe-function',
 `Info-goto-emacs-command-node', `name-last-kbd-macro',
 `insert-kbd-macro', `enable-command', `disable-command',
 `cancel-function-timers'.

Vanilla Emacs more commonly offers no default value beyond the car of the
history list (e.g. `Info-goto-emacs-command-node'), or it offers no
completion at all (e.g. `name-last-kbd-macro'). When a command is defined,
for instance, using only (interactive "aFunction: ") or (interactive
"CCommand: "), there is no useful default value available to the user, even
though it is often the case that it would be useful for `M-n' to insert the
word, symbol (name), etc. nearest the cursor.

For use as a variable value or a function argument, you would need to wrap
your code with `lambda', so, instead of just 'lisp-symbol-name-at-point, you
would need (lambda () (with-syntax-table emacs-lisp-mode-syntax-table
(symbol-name (thing-at-point 'symbol)))). Same thing, yes, but much less
convenient.

> Similarly, if you need a symbol rather than a string calling `intern' is
> trivial enough that there's no justification for a separate function.

Convenience is the justification. These are convenience functions. Their
typical use is as a funarg or variable value.