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

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

[Drew Adams]

Just a heads-up, so far.  This happens with my setup.  It has been
happening for a few weeks now.  It never happened before that (with
any Emacs version).  It happens occasionally, and I have not noticed
just when it happens.

What happens?  The title in the title bar of my standalone minibuffer
frame somehow, somewhen, is changed to be the same as the title of
another frame (no other frame in particular).

My minibuffer frame has this title to start with, and itshould remain:

  Emacs minibuffer               show/hide: hold CTRL + click in window

This is frame parameter `name' for the minibuffer frame.

Does this perhaps ring a bell wrt some Emacs change in, say, the last
month or so?  I'll keep looking, and maybe I will notice when the name
gets changed (it's not easy to notice).  If I do, I'll update the bug
with whatever else I find out.



In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-02 on ODIEONE
Bzr revision: 116242 rudalics@gmx.at-20140202130041-n967dw77nw7ztvy9
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

[Eli Zaretskii]

> Date: Wed, 5 Feb 2014 15:33:11 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> My minibuffer frame has this title to start with, and itshould remain:
> 
>   Emacs minibuffer               show/hide: hold CTRL + click in window
> 
> This is frame parameter `name' for the minibuffer frame.

When the title changes on display, does the frame parameter change as
well?

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

[Drew Adams]

> When the title changes on display, does the frame parameter change
> as well?

Dunno.  I presumed so.  I'll check that the next time this happens.

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

[Drew Adams]

> > When the title changes on display, does the frame parameter change
> > as well?
> 
> Dunno.  I presumed so.  I'll check that the next time this happens.

The answer is yes, frame parameter `name' gets changed.

Note that parameter `explicit-name' is t, as well (as it is at the
outset, in my setup).  And parameter `title' is nil (as it is at
the outset).

The bug, wherever it might be, seems to be that `name' is getting changed.

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

[Eli Zaretskii]

> Date: Thu, 6 Feb 2014 10:42:10 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16661@debbugs.gnu.org
> 
> > > When the title changes on display, does the frame parameter change
> > > as well?
> > 
> > Dunno.  I presumed so.  I'll check that the next time this happens.
> 
> The answer is yes, frame parameter `name' gets changed.

So what code can possibly change frame parameters like that?

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

[Drew Adams]

> > yes, frame parameter `name' gets changed.
> 
> So what code can possibly change frame parameters like that?

Not sure what you are asking.  Are you asking how to change a
frame parameter value?  `modify-frame-parameters', for example.

AFAIK  I have not changed my code in any way that would affect
this, but I could of course be mistaken.  My guess is that some
change in Emacs has brought about this behavior.

I do automatically call a function when iconifying/thumbifying
that updates the frame name to be its buffer name, but that
function specifically does not act on my minibuffer frame.

And if that were not working properly then the minibuffer
frame would get the name *Minibuf-0* or whatever, not the name
of an ordinary buffer, which is what I am seeing.  And this
code has anyway been used without change for decades.

Other than that, AFAIK I do not mess with a frame's `name'
parameter.  So in sum, I never mess with the minibuffer
frame's `name' parameter, once I've set it during startup.

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

[Juanma Barranquero]

On Thu, Feb 6, 2014 at 9:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> So what code can possibly change frame parameters like that?

The frameset stuff, perhaps, if frames (or the desktop) are being
saved/restored. But from Drew's description I think that's not what's
happening here.

    J

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

[Drew Adams]

> > So what code can possibly change frame parameters like that?
> 
> The frameset stuff, perhaps, if frames (or the desktop) are being
> saved/restored. But from Drew's description I think that's not
> what's happening here.

Yes, I have not (knowingly, at least) been using desktop stuff
or frameset stuff.

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

[Juanma Barranquero]

On Fri, Feb 7, 2014 at 3:36 AM, Drew Adams <drew.adams@oracle.com> wrote:

> Yes, I have not (knowingly, at least) been using desktop stuff
> or frameset stuff.

Well, frameset saving&restoring is automatically enabled, but what I
mean is, you do see the frame name change in a session, not between
sessions, do you? Because if you have a named frame, save and restore
(with desktop.el) and the frame name changes, that could be a frameset
problem. By default, frameset-save does not save the name parameter,
so if you set it in one session and then restore in another, the frame
won't have the name you set it to (unless you set it again).

Just as a test, try adding

  (push '(name . nil) frameset-filter-alist)

in your .emacs, after (require 'desktop), to check if that makes your
problem disappear.

    J

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

[Drew Adams]

> > Yes, I have not (knowingly, at least) been using desktop stuff
> > or frameset stuff.
> 
> Well, frameset saving&restoring is automatically enabled, but what I
> mean is, you do see the frame name change in a session, not between
> sessions, do you? 

Correct.  I notice it at some point (I've never noticed it change)
during the same session.  It starts out correct but changes at
some point.

And I don't think the frameset stuff has changed recently, has it?

> Because if you have a named frame, save and restore (with
> desktop.el) and the frame name changes, that could be a frameset
> problem. 

Nope; I'm not doing that.  Just one session.  My code names the
frame during my setup.  Nothing that I am aware of changes it
later, but something obviously does (in the same session).

> Just as a test, try adding
>   (push '(name . nil) frameset-filter-alist)
> in your .emacs, after (require 'desktop), to check if that makes
> your problem disappear.

Based on what I said above, do you really suggest that I do that?
Besides, `C-h v features' shows that `desktop' is not even loaded
in my session  (I don't do `(require 'desktop)').

I suppose that something might load desktop.el later, and that
could conceivably somehow provoke the problem.  But unless you
think it really might help, I won't bother to look there.

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

[Juanma Barranquero]

On Fri, Feb 7, 2014 at 4:08 AM, Drew Adams <drew.adams@oracle.com> wrote:

> Correct.  I notice it at some point (I've never noticed it change)
> during the same session.  It starts out correct but changes at
> some point.

OK.

> And I don't think the frameset stuff has changed recently, has it?

No, but windows & frame stuff has (Martin's been busy fixing bugs) and
I wouldn't be surprised to find some regression in frameset.el.

> Based on what I said above, do you really suggest that I do that?
> Besides, `C-h v features' shows that `desktop' is not even loaded
> in my session  (I don't do `(require 'desktop)').

No, if desktop.el and/or frameset.el are not loaded, it does not make
sense to try my suggestion.

    J

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

[Eli Zaretskii]

> Date: Thu, 6 Feb 2014 13:06:27 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16661@debbugs.gnu.org
> 
> > > yes, frame parameter `name' gets changed.
> > 
> > So what code can possibly change frame parameters like that?
> 
> Not sure what you are asking.  Are you asking how to change a
> frame parameter value?

No, I'm asking what code could do that.

Perhaps advising modify-frame-parameters and modify-frame-parameter,
to record their changes in some buffer, could find out the answer.

Or maybe try describing what you did immediately prior to this change
(aided by "C-h l"), and then you or someone else might have an idea.

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

[Drew Adams]

> Perhaps advising modify-frame-parameters and modify-frame-parameter,
> to record their changes in some buffer, could find out the answer.

I might do that; dunno.

> Or maybe try describing what you did immediately prior to this
> change (aided by "C-h l"), and then you or someone else might
> have an idea.

As I've tried to say a few times now, I have no idea whent this
occurs.  I do not notice the frame title changing.  At some point
I happen to see that it has changed.  I have no idea what I or
Emacs was doing immediately prior to the change.  If I did, I
would of course have reported that.  And I will do so, if I do
happen to notice the title changing.

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

[Drew Adams]

> > Perhaps advising modify-frame-parameters and modify-frame-
> > parameter, to record their changes in some buffer, could
> > find out the answer.
> 
> I might do that; dunno.

I'm afraid that would produce too much noise in *Messages*, as
there are lots of calls to `modify-frame-parameters'.  But I'll
think about it.

> > Or maybe try describing what you did immediately prior to this
> > change (aided by "C-h l"), and then you or someone else might
> > have an idea.
> 
> As I've tried to say a few times now, I have no idea whent this
> occurs.  I do not notice the frame title changing.  At some point
> I happen to see that it has changed.  I have no idea what I or
> Emacs was doing immediately prior to the change.  If I did, I
> would of course have reported that.  And I will do so, if I do
> happen to notice the title changing.

My thinking more and more is that this is happening randomly,
in the sense that it is unrelated to whatever I might be doing.

It just happened in a new session, before I had done more than
a couple double-clicks in a Dired buffer (IIRC).  Nothing in
*Messages*, and could not repro it doing the same thing in
another new session.  I have a vague suspicion that it might
somehow have to do with opening another Emacs session using
emacs -Q, but I have no real basis for thinking that.

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

[Eli Zaretskii]

> Date: Fri, 14 Feb 2014 07:51:38 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16661@debbugs.gnu.org
> 
> > > Perhaps advising modify-frame-parameters and modify-frame-
> > > parameter, to record their changes in some buffer, could
> > > find out the answer.
> > 
> > I might do that; dunno.
> 
> I'm afraid that would produce too much noise in *Messages*, as
> there are lots of calls to `modify-frame-parameters'.  But I'll
> think about it.

I didn't suggest to put the results in *Messages*.  You could use a
separate buffer for that.

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

[Drew Adams]

> > > > Perhaps advising modify-frame-parameters and modify-frame-
> > > > parameter, to record their changes in some buffer, could
> > > > find out the answer.
> You could use a separate buffer for that.

I tried that and got lucky (the problem arose), but it didn't
give me any info that is useful, I'm afraid.  Perhaps you have
a suggestion of something better/additional to print out?

Here is the info that was printed:

000 this-cmd: nil, last-cmd: nil
	(name . "drews-lisp-20")
 111 this-cmd: nil, last-cmd: nil
	(name . "drews-lisp-20")

All that tells us is that (a) it was `modify-frame-parameters',
not `set-frame-parameter', that caused the name change, and
(b) both `this-command' and `last-command' were nil when that
happened.

`drews-lisp-20' is a Dired buffer in a separate frame - the only
frame that existed at the time, apart from the minibuffer frame.
(I think that I have seen this bug only when there is only one
other frame besides the minibuffer frame.)

This is the code that printed that debug info:

(defadvice modify-frame-parameters (around mini-debug activate)
  (when (and (eq (ad-get-arg 0) 1on1-minibuffer-frame)
             (assoc 'name (ad-get-arg 1))) 
    (with-current-buffer (get-buffer-create "*MINI-DEBUG*")
      (let ((str  (format "000 this-cmd: %S, last-cmd: %S\n\t%S\n"
                          this-command last-command
                          (assoc 'name (ad-get-arg 1)))))
        (insert str))))
  ad-do-it
  (when (and (eq (ad-get-arg 0) 1on1-minibuffer-frame)
             (assoc 'name (ad-get-arg 1)))
    (with-current-buffer (get-buffer-create "*MINI-DEBUG*")
      (let ((str  (format " 111 this-cmd: %S, last-cmd: %S\n\t%S\n"
                          this-command last-command
                          (assoc 'name (ad-get-arg 1)))))
        (insert str)))))

(defadvice set-frame-parameter (around mini-debug activate)
  (when (and (eq (ad-get-arg 0) 1on1-minibuffer-frame)
             (eq 'name (ad-get-arg 1))) 
    (with-current-buffer (get-buffer-create "*MINI-DEBUG*")
      (let ((str  (format "333 this-cmd: %S, last-cmd: %S\n\t%S\n"
                          this-command last-command (ad-get-arg 2))))
        (insert str))))
  ad-do-it
  (when (and (eq (ad-get-arg 0) 1on1-minibuffer-frame)
             (eq 'name (ad-get-arg 1)))
    (with-current-buffer (get-buffer-create "*MINI-DEBUG*")
      (let ((str  (format " 444 this-cmd: %S, last-cmd: %S\n\t%S\n"
                          this-command last-command (ad-get-arg 2))))
        (insert str)))))

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

[Drew Adams]

> I tried that and got lucky (the problem arose), but it didn't
> give me any info that is useful, I'm afraid.  Perhaps you have
> a suggestion of something better/additional to print out?
> 
> Here is the info that was printed:
> 
> 000 this-cmd: nil, last-cmd: nil
> 	(name . "drews-lisp-20")
>  111 this-cmd: nil, last-cmd: nil
> 	(name . "drews-lisp-20")

This happened again, with the same info printed out.
Any suggestion of other information to print out?

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

[Eli Zaretskii]

> Date: Wed, 19 Feb 2014 13:06:40 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16661@debbugs.gnu.org
> 
> > 000 this-cmd: nil, last-cmd: nil
> > 	(name . "drews-lisp-20")
> >  111 this-cmd: nil, last-cmd: nil
> > 	(name . "drews-lisp-20")
> 
> This happened again, with the same info printed out.
> Any suggestion of other information to print out?

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

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Fri, 21 Feb 2014 20:23:47 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16661@debbugs.gnu.org
> 
> > 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))

I'm confused: window-setup-hook is called only once, as part of Emacs
startup.  Are you saying that all these cases of renaming happened
during Emacs startup, and only at that time?  I somehow decided,
probably erroneously, that the renaming randomly happened during a
running session.

> Why should the `buffer-name' of the minibuffer frame be
> different from the frame name, for the minibuffer frame?

AFAIK, buffer-name in the minibuffer always returns the name of the
buffer which caused minibuffer to be entered.  Anything else would be
highly confusing, e.g. "M-: (buffer-name) RET" surely must return the
name of the invoking buffer.

IOW, I think that buffer-name in the minibuffer is unreliable, if you
want to get the name of the minibuffer itself.

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

[Drew Adams]

> I'm confused:

Probably not as much as I.

> window-setup-hook is called only once, as part of Emacs
> startup.

Yes, and I'm sorry that I do not recall just why I do that add-hook.
I have used it ever since I've used a standalone minibuffer frame,
I believe, but I can try without it.  I have this comment next
to that code, but again, I do not recall what the problem was:

;;; A HACK FOR WINDOWS

> Are you saying that all these cases of renaming happened
> during Emacs startup, and only at that time?  I somehow decided,
> probably erroneously, that the renaming randomly happened during a
> running session.

What I have observed, irrespective of the debugging output, is that:

a. Initially, after startup, things are normal wrt frame names.
b. Sometime later, in the middle of a session, the bug arises.

The order of what I do at startup is this:

1. Rename the newly created minibuffer frame to the name it should
have always.  (I do this in oneonone.el.)

2. Do the add-hook for `window-setup-hook'.

> > Why should the `buffer-name' of the minibuffer frame be
> > different from the frame name, for the minibuffer frame?
> 
> AFAIK, buffer-name in the minibuffer always returns the name of the
> buffer which caused minibuffer to be entered.  Anything else would be
> highly confusing, e.g. "M-: (buffer-name) RET" surely must return the
> name of the invoking buffer.

Not if you select the standalone minibuffer frame (e.g., click mouse-1
on its title bar).  In that case, `M-: (buffer-name)' shows the
minibuffer's buffer name: ` *Minibuf-N*', N=0,1,2...

This is as it should be.  No problem with that.

> IOW, I think that buffer-name in the minibuffer is unreliable, if you
> want to get the name of the minibuffer itself.

The buffer displayed in the minibuffer window is typically named
` *Minibuf-N*', N=0,1,2...  It is still named this way with my
setup.  The only thing I change is the `name' parameter of the
frame.

I will try removing the `window-setup-hook' renaming, to see whether
that makes a difference.

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

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

[Drew Adams]

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

Good point; the default for non-interactive use was flaky.

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

Yes.

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> The buffer displayed in the minibuffer window is typically named
> ` *Minibuf-N*', N=0,1,2...  It is still named this way with my
> setup.  The only thing I change is the `name' parameter of the
> frame.
>
> I will try removing the `window-setup-hook' renaming, to see whether
> that makes a difference.

Are you still seeing problems in this area?  If so, please try to create
a recipe starting from -Q.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> Are you still seeing problems in this area?  If so, please try to create
> a recipe starting from -Q.

No, I think this can be closed.  Thx.