Buffer names are sometimes read-only objects in daemonized emacs (was: How do I debug errors in post-command-hook?)

[Tassilo Horn]

On Friday 30 July 2010 13:58:59 Johan Bockgård wrote:

Hi Johan,

> >> (defadvice lusty--post-command-function (around intercept activate)
> >>   (condition-case err
> >>       ad-do-it
> >>     ;; Let the debugger run
> >>     ((debug error) (signal (car err) (cdr err)))))
> >
> > That didn't enter the debugger.
> 
> You need to turn on debug-on-error.

Oh, indeed.  Then it did work, and here's the backtrace.

--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (error "Attempt to modify read-only object")
  put-text-property(0 11 face font-lock-string-face "*GNU Emacs*")
  byte-code("address@hidden     
address@hidden))I\210\fT\211Y\203kT\211Y\203c\313\314\306\"\210\202iH\311\nA\211\204*\306\207"
 [items item --cl-dolist-temp-- col-vec y path nil 47 put-text-property 0 face 
throw --cl-block-nil-- last lusty-directory-face lusty-slash-face 
lusty-file-face optimal-n-rows x n-columns matrix] 9)
  lusty--compute-layout-matrix(("*GNU Emacs*" "*Messages*" "diary" "*scratch*"))
  lusty-refresh-matches-buffer()
  ad-Orig-lusty--post-command-function()
  (setq ad-return-value (ad-Orig-lusty--post-command-function))
  (condition-case err (setq ad-return-value 
(ad-Orig-lusty--post-command-function)) ((debug error) (signal ... ...)))
  (let (ad-return-value) (condition-case err (setq ad-return-value ...) (... 
...)) ad-return-value)
  lusty--post-command-function()
  run-hooks(post-command-hook)
  ad-Orig-read-buffer(">> " nil nil)
  (setq ad-return-value (ad-Orig-read-buffer prompt def require-match))
  (let ((completion-styles ...)) (setq ad-return-value (ad-Orig-read-buffer 
prompt def require-match)))
  (let (ad-return-value) (let (...) (setq ad-return-value ...)) ad-return-value)
  read-buffer(">> ")
  apply(read-buffer ">> " nil)
  lusty--run(read-buffer)
  lusty-buffer-explorer()
  call-interactively(lusty-buffer-explorer nil nil)
--8<---------------cut here---------------end--------------->8---

Looking at the lusty-explorer code, `lusty--compute-layout-matrix' calls
a defsubst `lusty-propertize-path' which eventually propertizes the
string given as parameter `path', like indicated by the top frame of the
backtrace:

    put-text-property(0 11 face font-lock-string-face "*GNU Emacs*")

But why does that throw an error when emacs is started as a daemon?

And, even in a daemonized emacs, I can eval

   (lusty-propertize-path "*GNU Emacs*")

without any problem.  So it looks like the string "*GNU Emacs*" passed
to that defsubst is somehow read-only.  Grepping the emacs sources the
error seems to be triggered by having that string in pure storage.  But
why?

The string is retrieved by collecting buffers using `walk-windows'
followed by `window-buffer' in combination with `buffer-list'.  Then for
all collected buffers, `buffer-name' is called, and those strings are
then passed to the `lusty-propertize-path' defsubst.

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

Thereby I realized that after evaling that, (buffer-name <some-buf>)
will return the propertized string, so it seems that `buffer-name'
doesn't return a string copy but a place in the CL sense.  I'm not sure
if that's correct?  (The same is true for a "normal" emacs.)

Can anyone enlighten me what's going on?

Bye,
Tassilo