[Top][All Lists]

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

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

From: martin rudalics
Subject: bug#20538: 24.4; Attempt to delete a surrogate minibuffer frame
Date: Tue, 12 May 2015 11:36:24 +0200

> 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

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


reply via email to

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