Re: Buffer names are sometimes read-only objects in daemonized emacs

[Wojciech Meyer <wojciech.meyer@googlemail.com>]

Tassilo Horn <tassilo@member.fsf.org> writes:

>> How would you do this? I see that the check can be performed on only
>> at runtime. Bytecompiler will not warn, because the value might be
>> propagated, and Lisp is dynamicaly typed. (in simple cases like this
>> it is apparent, but consider just returning this value from function).
>
> No no, you got me wrong.  I just meant the docstring of `buffer-name'
> (and any other function that returns some thing whose modification would
> have undesired, non-obvious side-effects) should explicitly state that
> modifying that returned string will indeed modify the buffer name.

Sry. I now got it.
The thing is that you should never modify inplace other string refs then
returned from make-string, the same applies to string literals.  e.g
text surounded by double quotes. (this could land easily in some read
only area). You could assume that all the string refs, are passed by
ref, and the string (mainly for performance reasons) will the same
object as in the buffer-list. So the advise is, modify inplace only if
you are sure it will not clobber the data in the other corner of Emacs
Also, Elisp has highly stateful nature, and it is hard to avoid such
quirks.

>
> Johan argued the other way round, that it's clear that you should not do
> that because the function doesn't explicitly state that the returned
> string is a fresh copy.

Yes, that's indeed better idea, as it will happen less often.

>
> Bye,
> Tassilo

Wojciech