From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Raffaele Ricciardi Newsgroups: gmane.emacs.help Subject: Re: thing-at-point: inconsistent behaviour? Date: Fri, 17 Aug 2012 10:23:40 +0100 Message-ID: References: 14343615082012@@ews.eternal-sepppppppppppp NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1345195517 14197 80.91.229.3 (17 Aug 2012 09:25:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Aug 2012 09:25:17 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 17 11:25:17 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T2Inp-00043X-Kt for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Aug 2012 11:25:13 +0200 Original-Received: from localhost ([::1]:39213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T2Ino-0007mY-FQ for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Aug 2012 05:25:12 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 96 Original-X-Trace: individual.net nhUNS/FVXSA5Bztitm2PHQ9jKg8kTiQX15Nm5OnJiaqZ6xCADeQe6YwXwPITWbrTnx Cancel-Lock: sha1:k0XG3i0so8QKP9k6+hthwFgEzzo= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Original-Xref: usenet.stanford.edu gnu.emacs.help:194022 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:86390 On 08/17/2012 05:38 AM, Drew Adams wrote: >>> In the case of a symbol, IMO most programs really want/need >>> to grab a symbol _name_, often for use as the default value >>> in an interactive spec. Most do not really want/need a Lisp >>> symbol. And even when they do, they can call `intern' >>> or `intern-soft' or `make-symbol' themselves. >> >> Then they should call (thing-at-point 'symbol), not >> (symbol-at-point). > > Yes. > > On the other hand, for many such use cases it is not very useful to obtain a > value of `nil' (a symbol, not a string) when there is no symbol name at point > (not even "nil"). Function `non-nil-symbol-name-at-point' returns "" in that > case. It is, in effect, (or (thing-at-point 'symbol) ""). > >> It seems like this tangent is because someone thought that the >> latter should just be a shorthand for the former, but they do >> different things and are intended for different situations. If >> symbol-at-point doesn't do what you want (e.g. it interns things >> when you would prefer it didn't), don't use it. No one's forcing >> you to. > > Exactly. And not just "someone" - such confusion does not seem that rare. > > You might have come to understand that (thing-at-point 'symbol) returns a > string, and you correctly distinguish it from what `symbol-at-point' does, but > it is easy for others not to get this. > > > This confusion wrt symbols is why it is helpful to provide a function that has > `symbol-name' and not just `symbol' in its name, the former doing, in effect, > what (or (thing-at-point 'symbol) "") does. > > BTW, I don't think most use cases really care whether or not the name has been > interned. What is more important usually is what kind of value is returned: a > symbol or a string (symbol name). > > The other thing that can be important for some use cases is to distinguish the > absence of any symbol name at point from the presence of the symbol name "nil" > at point. When picking up a symbol name to serve as a completion candidate for > some input, it is often the case that "nil" is not appropriate. > > FWIW, this 2007 Emacs Devel thread discusses exactly what is being discussed in > the present thread, and a bit more: > > http://lists.gnu.org/archive/html/emacs-devel/2007-07/msg01520.html > > Indeed there is ambiguity in the naming of `symbol-at-point', for as Drew has pointed out in another reply of his, `symbol' is a context-sensitive term, e.g. an Emacs Lisp symbol or a symbol according to the active syntax table. As such, users could oversee that `symbol-at-point' works only in the context of Emacs Lisp programs. As a counterexample, the specificity of `list-at-point' and 'sexp-at-point' is obvious. Maybe `symbol-at-point' could document that it returns the interned Emacs Lisp symbol at point, thus avoiding any confusion? Also, the documentation string could redirect to `thing-at-point' - or to a new `symbol-name-at-point' function - users who want to distinguish between no symbol and `nil'. > Especially since `thing-at-point' does NOT always return a string - > it returns a > list for (thing-at-point 'list), for instance. There is nothing in the name, > i.e., on the surface of it, that tells you that (thing-at-point 'symbol) returns > either a symbol name or the symbol `nil'. It looks every bit like it might > return the thing at point that is a symbol. On my GNU Emacs 24.1, `thing-at-point' always returns a (propertized) string, including when used with 'list.