symbol-at-point

symbol-at-point

[Andreas Röhler]

AFAIU implementation of `symbol-at-point' is not
straightforward in relation with other thing at point
functions:

These return THING as a substring of buffer, doing
nothing else, whereas symbol-at-point interns existing
THING unconditionally

(defun symbol-at-point ()
  (let ((thing (thing-at-point 'symbol)))
    (if thing (intern thing))))

Wouldn't it be more clean to write a separate (intern
SYMBOL-at-point) function, if someone wants to do that?

Thanks

Andreas Roehler

Re: symbol-at-point

[Eli Zaretskii]

> From: Andreas =?iso-8859-1?q?R=F6hler?= <andreas.roehler@online.de>
> Date: Thu, 26 Jul 2007 11:07:28 +0200
> 
> These return THING as a substring of buffer, doing
> nothing else, whereas symbol-at-point interns existing
> THING unconditionally

And why is that bad, actually?

Re: symbol-at-point

[Andreas Röhler]

Am Donnerstag, 26. Juli 2007 14:20 schrieb Eli Zaretskii:
> > From: Andreas =?iso-8859-1?q?R=F6hler?= <andreas.roehler@online.de>
> > Date: Thu, 26 Jul 2007 11:07:28 +0200
> >
> > These return THING as a substring of buffer, doing
> > nothing else, whereas symbol-at-point interns existing
> > THING unconditionally
>
> And why is that bad, actually?
>
Probably my concern is solely imaginative:

let's consider a case, where a program checks for
symbolp and makes action depend from it.

Then you may have changed situation by calling
symbol-at-point while editing some code.

Its a little bit as url-at-point would not simply
return the string, but follow that url then.

Or email-at-point would call the mailer.
 
Andreas Roehler

Re: symbol-at-point

[Eli Zaretskii]

> From: Andreas =?utf-8?q?R=C3=B6hler?= <andreas.roehler@online.de>
> Date: Thu, 26 Jul 2007 20:45:21 +0200
> Cc: Tassilo Horn <tassilo@member.fsf.org>,
>  emacs-devel@gnu.org
> 
> let's consider a case, where a program checks for
> symbolp and makes action depend from it.
> 
> Then you may have changed situation by calling
> symbol-at-point while editing some code.

Then why wouldn't such a program call thing-at-point instead?

Re: symbol-at-point

[Tassilo Horn]

Andreas Röhler <andreas.roehler@online.de> writes:

> AFAIU implementation of `symbol-at-point' is not straightforward in
> relation with other thing at point functions:
>
> These return THING as a substring of buffer, doing nothing else,

Yeah, because most THINGs are strings. An url is a string, a filename is
a string, ...

> whereas symbol-at-point interns existing THING unconditionally

Well, the THING symbol clearly is not a string.

> Wouldn't it be more clean to write a separate (intern SYMBOL-at-point)
> function, if someone wants to do that?

It would be very confusing if a function named `symbol-at-point'
wouldn't return a symbol (or nil if there's no symbol at point).

Bye,
Tassilo
-- 
The  desire  to  be  rewarded  for one's  creativity  does  not  justify
depriving  the world  in  general of  all  or part  of that  creativity.
(Richard M. Stallman)

Re: symbol-at-point

[Stefan Monnier]

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

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


        Stefan

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.

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

Re: symbol-at-point

[Stefan Monnier]

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

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

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

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


        Stefan

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.

Re: symbol-at-point

[Stefan Monnier]

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

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

Re: symbol-at-point

[Stefan Monnier]

> 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'm pretty sure that <foo>-near-point would not make authors provide default
values in more cases.  <foo>-at-point works well enough in most cases that
it's hard to believe an author would say "oh, no: I want <foo>-near-point or
nothing at all.  None of that <foo>-at-point crap!"

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

Problem is that "nil" is a perfectly normal identifier in most languages.


        Stefan