bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#16661: 24.3.50; standalone minibuffer frame gets renamed with name of aother frame
Date: Fri, 21 Feb 2014 20:23:47 -0800 (PST)

> How about adding a Lisp backtrace to the info you already put there?

OK, I have some more info about this.  This is the backtrace:

000 this-cmd: nil, last-cmd: nil
        (name . "drews-lisp-20")
  backtrace()
  ad-Advice-modify-frame-parameters(#<subr modify-frame-parameters> #<frame 
Emacs minibuffer                         show/hide: hold CTRL + click in window 
03bec000> ((name . "drews-lisp-20")))
  apply(ad-Advice-modify-frame-parameters #<subr modify-frame-parameters> 
(#<frame Emacs minibuffer                         show/hide: hold CTRL + click 
in window 03bec000> ((name . "drews-lisp-20"))))
  modify-frame-parameters(#<frame Emacs minibuffer                         
show/hide: hold CTRL + click in window 03bec000> ((name . "drews-lisp-20")))
  rename-frame()
  run-hooks(window-setup-hook)

I do this in my init file:

(when (and (if (fboundp 'display-graphic-p) (display-graphic-p) window-system)
           (eq system-type 'windows-nt) (fboundp 'rename-frame))
  (add-hook 'window-setup-hook 'rename-frame))

This is `rename-frame':

(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.
  (let ((fr  (get-a-frame old-name))) ; Convert to frame if string.
    (if all-named
        (while fr
          (modify-frame-parameters fr (list (cons 'name new-name)))
          (setq fr  (get-a-frame old-name))) ; Get another.
      (when (string= (get-frame-name fr) (get-frame-name))
        (setq fr  (selected-frame)))
      (modify-frame-parameters fr (list (cons 'name new-name))))))

What's odd is that I never saw the minibuffer get renamed to another
buffer name before now.  And even now it happens only occasionally.

I will switch to using my function `rename-non-minibuffer-frame',
which I hope will take care of the problem I see.

But I wonder whether this might not indicate an Emacs bug.  Either
a new bug: Why should the `buffer-name' of the minibuffer frame be
different from the frame name, for the minibuffer frame?

Apparently Emacs thinks that the current buffer in the minibuffer
frame is the buffer of another frame (in this case, Dired).  And
I believe that I have seen this renaming bug happen only when
there is only one other frame, besides the minibuffer frame.
How is it possible that (buffer-name) is the name of a Dired
buffer when `window-setup-hook' is called for the minibuffer
frame?

Or perhaps some old bug was fixed, which causes me to see this
for the first time (across all Emacs versions from Emacs 20-24)?
But even in that case I have the same questions: why would
`buffer-name' be wrong when `window-setup-hook' is run?

Anyone have insight into this?  I believe I first started seeing
this in early January, but it might have been a little before or
after that.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]