From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: symbol-at-point Date: Fri, 27 Jul 2007 01:36:16 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1185514597 11249 80.91.229.12 (27 Jul 2007 05:36:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2007 05:36:37 +0000 (UTC) Cc: Andreas Rohler , emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 27 07:36:35 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 1IEIV9-0003i9-7k for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 07:36:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEIV8-00044u-KJ for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 01:36:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IEIV5-00044h-Ij for emacs-devel@gnu.org; Fri, 27 Jul 2007 01:36:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IEIV3-00044U-61 for emacs-devel@gnu.org; Fri, 27 Jul 2007 01:36:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEIV3-00044R-0r for emacs-devel@gnu.org; Fri, 27 Jul 2007 01:36:29 -0400 Original-Received: from tomts16.bellnexxia.net ([209.226.175.4] helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IEIV2-00015E-Ll for emacs-devel@gnu.org; Fri, 27 Jul 2007 01:36:28 -0400 Original-Received: from pastel.home ([70.53.195.62]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070727053625.CMTE574.tomts16-srv.bellnexxia.net@pastel.home> for ; Fri, 27 Jul 2007 01:36:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 737BF80A6; Fri, 27 Jul 2007 01:36:16 -0400 (EDT) In-Reply-To: (Drew Adams's message of "Thu\, 26 Jul 2007 13\:31\:45 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Solaris 8 (1) 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:75619 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). > 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