bug#16661: 24.3.50; standalone minibuffer frame gets renamed with name of aother frame

[Stefan Monnier]

>   rename-frame()
>   run-hooks(window-setup-hook)

[...]

> (defun rename-frame (&optional old-name new-name all-named)
>   "Rename a frame named OLD-NAME to NEW-NAME.
> Prefix arg non-nil means rename all frames named OLD-NAME to NEWNAME.
> OLD-NAME may be a frame, its name, or nil.  Default is `selected-frame'.
> NEW-NAME is a string or nil.  Default NEW-NAME is current `buffer-name'."
>   (interactive
>    (list (read-frame
>            (concat "Rename " (and current-prefix-arg  "all ")
>                    "frame" (and current-prefix-arg  "s named") ": ")
>            nil t)             ; Default = selected.  Must exist.
>          (read-from-minibuffer "Rename to (new name): "
>                                (cons (buffer-name) 1))
>          current-prefix-arg))
>   (setq old-name  (or old-name  (get-frame-name)) ; Batch default: current.
>         new-name  (or new-name  (buffer-name))) ; Batch default: buf name.

When called from window-setup-hook, you have no guarantee about what is
the current buffer.  It may be a buffer that's not even displayed.
So you want to use (window-buffer (frame-selected-window)) rather than
current-buffer, here.

Not sure if it's related to your actual bug, tho, since
window-setup-hook is only run once at startup and your problem seems to
happen later.


        Stefan