bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

I do not know how I got into this (sorry, I do not have a recipe to
reproduce this either).  I have a frame I want to delete by running
delete-frame.  Yet this only gives me the error message

  "Attempt to delete a surrogate minibuffer frame"

and delete-frame refuses to do its job.  What does this mean?  If
nothing else, Emacs could do a better job explaining to the user
what it believes is going on and how the user can possibly resolve
this.

Possibly a relevant detail: I like to run Ediff sessions with one
split frame showing both buffers I need to compare.  Yet Ediff
sometimes comes up with its own ideas about resources it likes to
use, grabbing another frame to show each buffer in a separate frame.
If I remember correctly this happened here, too, that is, maybe
Emacs believes that the frame I want to delete was/is part of the
Ediff session.

PS: Neither the Emacs nor the Elisp manual mention "surrogate" in
any context.




In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2014-10-26 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.5 LTS

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.ISO-8859-15
  locale-coding-system: iso-latin-9-unix

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Eli Zaretskii]

> Date: Sat, 09 May 2015 14:35:40 -0500
> From: "Roland Winkler" <winkler@gnu.org>
> 
> 
> I do not know how I got into this (sorry, I do not have a recipe to
> reproduce this either).  I have a frame I want to delete by running
> delete-frame.  Yet this only gives me the error message
> 
>   "Attempt to delete a surrogate minibuffer frame"
> 
> and delete-frame refuses to do its job.  What does this mean?

It means you tried to delete a frame that serves as a minibuffer for
another frame.

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 > I do not know how I got into this (sorry, I do not have a recipe to
 > reproduce this either).  I have a frame I want to delete by running
 > delete-frame.  Yet this only gives me the error message
 >
 >    "Attempt to delete a surrogate minibuffer frame"
 >
 > and delete-frame refuses to do its job.  What does this mean?  If
 > nothing else, Emacs could do a better job explaining to the user
 > what it believes is going on and how the user can possibly resolve
 > this.
 >
 > Possibly a relevant detail: I like to run Ediff sessions with one
 > split frame showing both buffers I need to compare.  Yet Ediff
 > sometimes comes up with its own ideas about resources it likes to
 > use, grabbing another frame to show each buffer in a separate frame.
 > If I remember correctly this happened here, too, that is, maybe
 > Emacs believes that the frame I want to delete was/is part of the
 > Ediff session.

It probably happens because ediff (by default) display the "control
panel" in a frame without minibuffer and Emacs doesn't allow to make
such a frame the last remaining one.

I use

(custom-set-variables
  '(ediff-window-setup-function (quote ediff-setup-windows-plain)))

which avoids that the control panel appears on a separate frame.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Sun May 10 2015 martin rudalics wrote:
> It probably happens because ediff (by default) display the "control
> panel" in a frame without minibuffer and Emacs doesn't allow to make
> such a frame the last remaining one.

Not exactly.

In the meanwhile, I noticed that the bug can be reproduced as
follows:

emacs -Q foo bar

M-x ediff-buffers ; to compare buffers foo and bar

; select buffer foo

C-x 5 2 ; display buffer foo in a 2nd window in new frame

; in the frame displaying buffers foo and bar

M-x delete-frame

Error: Attempt to delete a surrogate minibuffer frame

; select the frame displaying the Ediff control panel

M-x delete-frame

Success!


It seems this should be the other way round: the "surrogate
minibuffer attribute" should be given to the frame displaying the
Ediff control panel instead of the frame displaying buffers foo and bar.

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Drew Adams]

> emacs -Q foo bar
> M-x ediff-buffers ; to compare buffers foo and bar
> ; select buffer foo
> 
> C-x 5 2 ; display buffer foo in a 2nd window in new frame

I was going to guess that it had something to do with having
one of the compared buffers in a separate frame, i.e., two
frames showing a buffer being compared.

That's been problematic all along, AFAIK.  It can make Ediff
tremble in the knees.  Especially if you do something like this:

> M-x delete-frame

That kind of thing can also result in Ediff screaming that
you've killed one of its relatives.

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Stefan Monnier]

> It seems this should be the other way round: the "surrogate
> minibuffer attribute" should be given to the frame displaying the
> Ediff control panel instead of the frame displaying buffers foo and bar.

Putting "surrogate minibuffer attribute" on a frame which doesn't even
have a minibuffer wouldn't make much sense.

But I guess it would make sense to indicate that this ediff-control
frame is kind of "secondary" or "transient" or "deletable if its
minibuffer disappears".  Maybe we could solve this one with a kind of
delete-window-hook similar to kill-buffer-hook, so ediff could use this
hook to auto-delete the ediff-control frame when you delete the
other windows.


        Stefan

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 >> It probably happens because ediff (by default) display the "control
 >> panel" in a frame without minibuffer and Emacs doesn't allow to make
 >> such a frame the last remaining one.
 >
 > Not exactly.
 >
 > In the meanwhile, I noticed that the bug can be reproduced as
 > follows:
 >
 > emacs -Q foo bar
 >
 > M-x ediff-buffers ; to compare buffers foo and bar
 >
 > ; select buffer foo
 >
 > C-x 5 2 ; display buffer foo in a 2nd window in new frame
 >
 > ; in the frame displaying buffers foo and bar
 >
 > M-x delete-frame
 >
 > Error: Attempt to delete a surrogate minibuffer frame

Because the "frame displaying buffers foo and bar" is the frame that has
the minibuffer for the minibuffer-less "frame displaying the Ediff
control panel".  As I said above you are not allowed to delete the frame
with the minibuffer because that would make the minibuffer-less frame
the last remaining one.

 > ; select the frame displaying the Ediff control panel
 >
 > M-x delete-frame
 >
 > Success!

That frame has no minibuffer.  Hence it cannot possibly serve as
surrogate minibuffer frame and you can delete it without any problems.

 > It seems this should be the other way round: the "surrogate
 > minibuffer attribute" should be given to the frame displaying the
 > Ediff control panel instead of the frame displaying buffers foo and bar.

The surrogate minibuffer frame is the one whose minibuffer substitutes
the non-existing minibuffer of the control panel frame.  This is how
ediff sets things up.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Mon May 11 2015 martin rudalics wrote:
> Because the "frame displaying buffers foo and bar" is the frame that has
> the minibuffer for the minibuffer-less "frame displaying the Ediff
> control panel".  As I said above you are not allowed to delete the frame
> with the minibuffer because that would make the minibuffer-less frame
> the last remaining one.
> 
>  > ; select the frame displaying the Ediff control panel
>  >
>  > M-x delete-frame
>  >
>  > Success!
> 
> That frame has no minibuffer.  Hence it cannot possibly serve as
> surrogate minibuffer frame and you can delete it without any problems.
> 
>  > It seems this should be the other way round: the "surrogate
>  > minibuffer attribute" should be given to the frame displaying the
>  > Ediff control panel instead of the frame displaying buffers foo and bar.
> 
> The surrogate minibuffer frame is the one whose minibuffer substitutes
> the non-existing minibuffer of the control panel frame.  This is how
> ediff sets things up.

I see, thank you, initially I was rather off with my interpretation
of what was happening.

My usage scenario is the following:

Normally I run emacs with always no more than two frames.  I create
a 2nd frame as needed, but I delete it when it is not needed anymore
so that it does not clutter the desktop.  An ediff session then adds
one more frame for the ediff control panel.  Yet during an ediff
session I can get side-tracked: the frame used for displaying the ediff
buffers A and B may get used for something else, then I create
another frame and finally I want to delete the frame that Ediff
wants to use as surrogate minibuffer frame.

I understand that the frame displaying the ediff control panel needs
*some* other frame to provide a minibuffer.  Is it necessary that a
particular frame serves this purpose?  Or would it be sufficient
that emacs made sure that always at least one frame has a proper
minibuffer?  (In the case of the ediff control panel, I believe it
is fair to assume that anyway this frame rarely requires a proper
minibuffer. For me, the control panel is effectively the minibuffer
for an ediff session: commands are entered in that buffer; there is
no need for "a minibuffer for the ediff minibuffer".)

If nothing else, it would be good if the error message issued when
attempting to delete a surrogate minibuffer frame could be improved:
I got this error message at a point when I was not thinking about
ediff, but I just wanted to get back to my default "one frame
setup"; and it happened I wanted to delete the wrong frame to
achieve this goal.

Roland

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 > My usage scenario is the following:
 >
 > Normally I run emacs with always no more than two frames.  I create
 > a 2nd frame as needed, but I delete it when it is not needed anymore
 > so that it does not clutter the desktop.  An ediff session then adds
 > one more frame for the ediff control panel.  Yet during an ediff
 > session I can get side-tracked: the frame used for displaying the ediff
 > buffers A and B may get used for something else, then I create
 > another frame and finally I want to delete the frame that Ediff
 > wants to use as surrogate minibuffer frame.

Such things happen to me all the time.  That's why I prefer
`ediff-setup-windows-plain' (and `split-window-horizontally' as
`ediff-split-window-function').

 > I understand that the frame displaying the ediff control panel needs
 > *some* other frame to provide a minibuffer.  Is it necessary that a
 > particular frame serves this purpose?  Or would it be sufficient
 > that emacs made sure that always at least one frame has a proper
 > minibuffer?  (In the case of the ediff control panel, I believe it
 > is fair to assume that anyway this frame rarely requires a proper
 > minibuffer. For me, the control panel is effectively the minibuffer
 > for an ediff session: commands are entered in that buffer; there is
 > no need for "a minibuffer for the ediff minibuffer".)

At any time every frame has a corresponding minibuffer window and that
window won't change for the frame's entire lifetime.

 > If nothing else, it would be good if the error message issued when
 > attempting to delete a surrogate minibuffer frame could be improved:
 > I got this error message at a point when I was not thinking about
 > ediff, but I just wanted to get back to my default "one frame
 > setup"; and it happened I wanted to delete the wrong frame to
 > achieve this goal.

The problem is that the entity that issues the message is not aware of
the intrinsics of ediff.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Tue May 12 2015 martin rudalics wrote:
> Such things happen to me all the time.  That's why I prefer
> `ediff-setup-windows-plain' (and `split-window-horizontally' as
> `ediff-split-window-function').

How do you use the undocumented function ediff-setup-windows-plain?
(Could this usage be properly documented?)

> The problem is that the entity that issues the message is not aware of
> the intrinsics of ediff.

Sure.  I was more thinking that quite generally the error message
talking about a "surrogate minibuffer frame" is a bit confusing if
one has no clue what this term means.  When I first saw this
message, I thought of something like a "minibuffer frame" that was
some kind of surrogate (which was why I thought this was supposed to
refer to the Ediff control panel that acts like a minibuffer for an
ediff session).

Perhaps the error message could be changed to something like

  "Attempt to delete frame with a surrogate minibuffer for frame XYZ"

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 > How do you use the undocumented function ediff-setup-windows-plain?
 > (Could this usage be properly documented?)

It's an option (a customizable variable).  Do

M-: (require 'ediff) RET

C-h v RET ediff-window-setup-function RET

 > Sure.  I was more thinking that quite generally the error message
 > talking about a "surrogate minibuffer frame" is a bit confusing if
 > one has no clue what this term means.  When I first saw this
 > message, I thought of something like a "minibuffer frame" that was
 > some kind of surrogate (which was why I thought this was supposed to
 > refer to the Ediff control panel that acts like a minibuffer for an
 > ediff session).
 >
 > Perhaps the error message could be changed to something like
 >
 >    "Attempt to delete frame with a surrogate minibuffer for frame XYZ"

Maybe we should say in the documentation of `delete-frame' something
like

   A frame may not be deleted if its minibuffer serves as surrogate
   minibuffer for another frame.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Wed May 13 2015 martin rudalics wrote:
>  > How do you use the undocumented function ediff-setup-windows-plain?
>  > (Could this usage be properly documented?)
> 
> It's an option (a customizable variable).  Do
> 
> M-: (require 'ediff) RET
> 
> C-h v RET ediff-window-setup-function RET

Thanks - so the option is ediff-window-setup-function.

I suggest to give the function ediff-setup-windows-plain a docstring
like

  Set up windows for Ediff in one frame.
  Useful as value for `ediff-window-setup-function'.

Then your previous email telling me only about the function
ediff-setup-windows-plain gives an ignorant user like myself already
all the info he needs.

>  > Perhaps the error message could be changed to something like
>  >
>  >    "Attempt to delete frame with a surrogate minibuffer for frame XYZ"

Is the problem with the above that frames do not have
selfexplanatory unique names?  Oh well, too bad.

> Maybe we should say in the documentation of `delete-frame' something
> like
> 
>    A frame may not be deleted if its minibuffer serves as surrogate
>    minibuffer for another frame.

Yes, thanks, that would be better than the current phrase.  If the
buzzword "surrogate" appears also in the corresponding section of
the elisp manual, I might have never started this thread.

Roland

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 > Then your previous email telling me only about the function
 > ediff-setup-windows-plain gives an ignorant user like myself already
 > all the info he needs.

Well, in my first mail in this thread I wrote

 >> I use
 >>
 >> (custom-set-variables
 >>  '(ediff-window-setup-function (quote ediff-setup-windows-plain)))
 >>
 >> which avoids that the control panel appears on a separate frame.

Hence I thought you would be already aware of the real nature of
`ediff-setup-windows-plain' ;-)

 >>   > Perhaps the error message could be changed to something like
 >>   >
 >>   >    "Attempt to delete frame with a surrogate minibuffer for frame XYZ"
 >
 > Is the problem with the above that frames do not have
 > selfexplanatory unique names?  Oh well, too bad.

We could use (frame-parameter frame 'name) but it's not unique.

 >> Maybe we should say in the documentation of `delete-frame' something
 >> like
 >>
 >>     A frame may not be deleted if its minibuffer serves as surrogate
 >>     minibuffer for another frame.
 >
 > Yes, thanks, that would be better than the current phrase.  If the
 > buzzword "surrogate" appears also in the corresponding section of
 > the elisp manual, I might have never started this thread.

OK.  Unless someone has a better idea I'll rewrite it that way.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Thu May 14 2015 martin rudalics wrote:
> Hence I thought you would be already aware of the real nature of
> `ediff-setup-windows-plain' ;-)

I am sorry this slipped through

> We could use (frame-parameter frame 'name) but it's not unique.

Yes, when the window manager shows the same name for multiple
frames, this is not really helpful.  Yet there is no simple solution
for this.

> OK.  Unless someone has a better idea I'll rewrite it that way.

Thanks,

Roland

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 >  > Yes, thanks, that would be better than the current phrase.  If the
 >  > buzzword "surrogate" appears also in the corresponding section of
 >  > the elisp manual, I might have never started this thread.

I updated the doc-string of `delete-frame' and the corresponding parts
of the Elisp manual in commit 448cacc..9a07af0.  Please have a look.

martin

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[Roland Winkler]

On Tue May 19 2015 martin rudalics wrote:
>  >  > Yes, thanks, that would be better than the current phrase.  If the
>  >  > buzzword "surrogate" appears also in the corresponding section of
>  >  > the elisp manual, I might have never started this thread.
> 
> I updated the doc-string of `delete-frame' and the corresponding parts
> of the Elisp manual in commit 448cacc..9a07af0.  Please have a look.

Looks fine to me.  Info-search "surrogate" in the elisp manual now
matches delete-frame.

bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame

[martin rudalics]

 > Looks fine to me.  Info-search "surrogate" in the elisp manual now
 > matches delete-frame.

So I'm closing this bug.

Thanks, martin