[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love

From: Ken Raeburn
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
User-agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu)

"Stefan Monnier" <monnier+gnu/address@hidden> 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")
    ELISP> (put-text-property 3 6 'some-prop 'some-val s)
    ELISP> (setq s2 (intern s))
    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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]