From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much) Date: Fri, 19 Jul 2002 08:56:23 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020704135240.4CBB.LEKTU@terra.es> <20020704164911.4CC1.LEKTU@terra.es> <200207181456.g6IEu0J25108@aztec.santafe.edu> <200207190423.g6J4N2A13705@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027083514 32010 127.0.0.1 (19 Jul 2002 12:58:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 19 Jul 2002 12:58:34 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17VXL2-0008Jw-00 for ; Fri, 19 Jul 2002 14:58:28 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17VXXQ-0004it-00 for ; Fri, 19 Jul 2002 15:11:16 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VXK0-0006mM-00; Fri, 19 Jul 2002 08:57:24 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VXJ3-0006ke-00; Fri, 19 Jul 2002 08:56:25 -0400 Original-Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6JCuNf04531; Fri, 19 Jul 2002 08:56:23 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17VXJ1-00007C-00; Fri, 19 Jul 2002 08:56:23 -0400 Original-To: "Stefan Monnier" In-Reply-To: <200207190423.g6J4N2A13705@rum.cs.yale.edu> ("Stefan Monnier"'s message of "Fri, 19 Jul 2002 00:23:02 -0400") Original-Lines: 48 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5895 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5895 "Stefan Monnier" writes: > Actually, this is a recent change, right ? In Emacs-21.2, `symbol-name' > always returns a string with no properties. In that case we should > probably also strip the properties when we create a new symbol, instead > of wasting those intervals. I don't know about 21.2, but it happens for me with: 21.1 - at work 21.1.50 - which I'm using daily at home (I *really* need to update...) 21.3.50 - built from very recent CVS sources Are you sure about 21.2? It would be odd for it to have been fixed there but not on the trunk. Here's the whole thing I'm doing to reproduce it in ielm: ELISP> (setq s "booga-booga") "booga-booga" ELISP> (put-text-property 3 6 'some-prop 'some-val s) nil ELISP> (setq s2 (intern s)) booga-booga ELISP> (symbol-name 'booga-booga) #("booga-booga" 0 3 nil 3 6 (some-prop some-val) 6 11 nil) I do think it makes sense for symbol-name's return value to have no text properties. >> An Emacs Lisp symbol's name can also be changed after interning, such >> that it won't be found when interning either the old name or >> (probably) the new name. > > This is undocumented and I don't know of any code that relies on it > (well, I know of some such code, but not in any elisp package). > I think it should be considered as a misfeature/bug (but I don't > think it's worth fixing unless the fix is to make the output of > `symbol-name' be read-only). Maybe if we had read-only strings.... > I'm pretty sure that Scheme's symbol-name (if such a function exists) > returns a brand new string. Which would be another difference -- retrieving the name twice would give two values not "eq?" while in Emacs Lisp they are "eq". So is *that* property something that anyone might rely on in their Lisp code?