From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: symbol-at-point Date: Fri, 27 Jul 2007 09:24:18 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1185553645 10927 80.91.229.12 (27 Jul 2007 16:27:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2007 16:27:25 +0000 (UTC) Cc: Andreas Rohler , emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 27 18:27:18 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IESel-0004PM-9T for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 18:27:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IESek-0005Xp-Lf for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 12:27:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IESeX-0004Bj-7H for emacs-devel@gnu.org; Fri, 27 Jul 2007 12:26:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IESeW-000478-5V for emacs-devel@gnu.org; Fri, 27 Jul 2007 12:26:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IESeV-00044c-RI for emacs-devel@gnu.org; Fri, 27 Jul 2007 12:26:56 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IESeV-0000O8-DF for emacs-devel@gnu.org; Fri, 27 Jul 2007 12:26:55 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l6RGQGuN001316; Fri, 27 Jul 2007 11:26:16 -0500 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l6R8i9fc019301; Fri, 27 Jul 2007 10:26:15 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-74-162.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3075491611185553463; Fri, 27 Jul 2007 09:24:23 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:75706 Archived-At: > >> > 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 `-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.