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

[Stefan Monnier]

> > 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

Looks like I was wrong then.  Sorry.

> 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.

I agree, but I'm not sure it matters enough to change `intern's behavior.

> >> 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....

My Emacs' strings are (mostly) read-only (as are its `defconst' variables).
It does introduce some breakage, but the use of `aset' on strings is
surprisingly infrequent.

> > 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?

I don't think I've ever seen code rely on it, but I like it from
a performance point of view.


        Stefan