RE: symbol-at-point

[Drew Adams]

Stefan, rather than reply to everything you said in detail, I'll just say
this -

I think Emacs commands would do well to more often (a) use completion and
(b) give users a reasonable default value (whether or not completion is
available). In many cases, an appropriate default value would be some text
that is at or near point.

That that does not happen much today might be partly due to `interactive'
not supporting it for its built-in strings (e.g. "C..."). It might also be
partly due to the fact that the `*-at-point' functions look only directly
under the cursor, no further.

There is only one call to `symbol-at-point' in the distributed files today.
Perhaps there were more uses of it in the past; I don't recall. There are a
few calls to `thing-at-point'. And there are some calls to more specific
functions, such as `variable-at-point', `find-tag-default', and
`function-called-at-point', which are similar but which don't bother to use
`thingatpt.el'.

But, generally, default values from the current buffer are not offered much
to users. There is no reason that Emacs can't provide a reasonable default
value most of the time, that is, a value other than just the first history
value (which is available anyway).

I would hope that thingatpt.el might encourage the use of buffer text at
point as a default value, but it apparently has not, so far. It's my hope
that the restriction to point has itself held back the use of thingatpt
functions, and that offering the "near" functions might help users get
better default values.

I use such default values in my own code, and I miss them whenever I use
vanilla Emacs. I use text at point for `grep' and `query-replace' as often
as I start isearch with `C-s C-w', for instance, which is quite often.

Beyond the question of providing default values, which can nearly always be
strings, I do think there is some value in providing functions that provide
other Lisp objects (lists, numbers, etc.) at or near point. But that, to me,
is secondary. In particular, losing `symbol-at-point' would be no great
loss, I agree.

(FWIW, the danger you see from a nil return value for `symbol-at-point' is
exaggerated, I think, since a non-nil symbol would generally be what is
sought. nil can always be interpreted as "no, there is no non-nil symbol at
point". Yes, the name of the function does not make this clear.)