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 14:56:15 -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 1185562611 8832 80.91.229.12 (27 Jul 2007 18:56:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2007 18:56:51 +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 20:56:44 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 1IEUzQ-0006vH-Tq for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 20:56:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEUzQ-00008t-9m for ged-emacs-devel@m.gmane.org; Fri, 27 Jul 2007 14:56:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IEUz5-0008TE-69 for emacs-devel@gnu.org; Fri, 27 Jul 2007 14:56:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IEUz3-0008Sp-JO for emacs-devel@gnu.org; Fri, 27 Jul 2007 14:56:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IEUz3-0008Sm-F7 for emacs-devel@gnu.org; Fri, 27 Jul 2007 14:56:17 -0400 Original-Received: from tomts25.bellnexxia.net ([209.226.175.188] helo=tomts25-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IEUz3-0006Q0-24 for emacs-devel@gnu.org; Fri, 27 Jul 2007 14:56:17 -0400 Original-Received: from pastel.home ([70.53.195.62]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070727185615.WQHT19497.tomts25-srv.bellnexxia.net@pastel.home> for ; Fri, 27 Jul 2007 14:56:15 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 27FFF80DA; Fri, 27 Jul 2007 14:56:14 -0400 (EDT) In-Reply-To: (Drew Adams's message of "Fri\, 27 Jul 2007 09\:24\:18 -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:75716 Archived-At: >> 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 > `-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