Re: symbol-at-point

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

I have no idea what you're trying to do here: I already said I agree.
But your example is still as bogus as before: for the new feature of "list
of strings" to make any difference to this argument, the "magically fixed"
code had to use a list of symbols, but these have never worked anyway.

> 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.

Eliminate bugs in major modes that use symbol-at-point.  Any major mode that
uses it will most likely handle the "nil" identifier incorrectly.

> 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.

Because it only introduces a bug in a corner case.

> My main complaint about it is that it is too limited, not looking beyond
> the exact cursor position.

That's a limitation of "thing-at-point", not specific to symbols.  And I can
agree that thing-near-point may be useful (tho probably not very useful).

> 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.

All uses I see in Elisp use direct calls, except for the internal ones
inside thingatpt.el.

> 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.

Indeed, and this is done by a direct call.

> 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 want to deprecate it based on the fact that you can use
thing-at-point instead but because returning a symbol rather than a string
loses information.

> 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)).

Agreed, and I never said I'd oppose

  (defun symbol-name-at-point () (thing-at-point 'symbol))

>> >> 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'.

No: (thing-at-point 'symbol) returns a string.

> 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*.

Right, and it can use the with-syntax-table instead now.

> 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).

Same thing holds (other than the spurious symbol-name which shouldn't be
there) for Perl symbols, Scheme symbols, C symbols, Haskell symbols, ...

> A common use for such functions would be as the value of a
> `<whatever>-default-input-fn' variable,

There is currently no such variable, so we'll cross this bridge when/if we
get to it.

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

Please grep for symbol-at-point in the existing Elisp code.  You'll see that
your notion of convenience is completely ridiculous.  I find only 1 use of
it (in cmuscheme.el) in Emacs, plus another one in haskell-mode (I hope
there are others in other packages I don't have installed here, but it
should give you an idea of the scale of use and hence the importance of
defining umpteen minor variants of it).


        Stefan