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

[Tassilo Horn]

On Friday 30 July 2010 19:46:28 Johan Bockgård wrote:

> > But even this does work in a daemonized emacs, even when I put it at
> > the front of my .emacs and then start it with emacs --daemon:
> >
> > (dolist (b (buffer-list))
> >   (let ((n (buffer-name (get-buffer b))))
> >     (put-text-property 0 (length n) 'face font-lock-string-face n)))
> 
> But this list does not contain "*GNU Emacs*", does it?

Nope.

> ("*GNU Emacs*" is the splash screen buffer. It is created after
> loading the init files.)
> 
> The daemon creates the splash screen via `normal-splash-screen'
> (instead of `fancy-startup-screen'). It contains a call to
> `(rename-buffer "*GNU Emacs*" t)'. Unlike `get-buffer-create',
> `rename-buffer' does not make a copy of the provided string. This is
> how the pure string ends up in `buffer-name', AFAICT.

But why is the string "*GNU Emacs*" put in pure space?  Because
everything that gets created when loading startup.el will be in pure
space?

> (Modifying a string returned by `buffer-name' is still evil, as it
> does not promise to return a fresh string.)

IMO a function shouldn't need to allow modification of it's return value
explicitly, but instead should warn if that's possible.  But indeed,
evaluating

  (aset (buffer-name) 0 ?g) 

makes my kmailCh3711.tmp buffer a gmailCh3711.tmp buffer.  To be honest,
this is really awkward.  Nobody would guess that modifying a string
returned by some function could have any side effects.

Bye,
Tassilo