Re: How to restore the layout?

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Jul 1, 2013 at 6:03 PM, Drew Adams <drew.adams@oracle.com> wrote:

> My guess is that, for the reasons I gave earlier (must set up during
> startup), someone using a standalone minibuffer frame will already have
> set it up, including its position and size, before trying to restore a
> desktop.  Users will neither want nor need a desktop to record and
> restore a standalone minibuffer frame.

In many cases, the user will already have set up other frames in
precise detail, the initial one for example (until now, I usually set
my initial frame with specific size & position). But if she moves the
frame and saves Emacs, she will expect the frame to restore at the new
position, not the one in initial-frame-alist. I don't really see why
moving a minibuffer-only frame from its default position should be
different (other that because it is harder to implement correctly, of
course ;-).

> My suggestion is to record & restore only the frames that do not have
> an `only' value for frame parameter `minibuffer'.  No one will miss the
> "feature" of recording & restoring a standalone minibuffer frame.

I've tested that and it works, but it is a bit jarring. Your frame
will restore at the same place it was saved, but the new minibuffer
frame is restored all over the place. Of course, if you set up
minibuffer-frame-alist for a specific position, it will be recreated
there, which is still jarring if you've moved the main frame.

That said, as a last resort I can live with not saving the
minibuffer-only frame and document clearly that the user is reponsible
of its appearance *and* position and should set minibuffer-frame-alist
correctly when using desktop-restore-frames.

> 1. Restoring a frame with nil `minibuffer' property correctly associates
> it with the standalone minibuffer frame.  I assume that that is the case,
> because that is what happens today when `default-frame-alist' specifies
> nil as the `minibuffer' property value.  That is the only that makes
> sense to me.

Yes.

> 2. Restoring a frame that had a non-nil, non-`only' `minibuffer' property
> correctly associates it with an existing standalone minibuffer frame.
> I assume that is the only reasonable behavior, but I'm no expert on that.
> Perhaps there is someone who uses both a standalone minibuffer and
> separate minibuffers in some frames?  I doubt it, however.

No idea.

> That is at least the first behavior to try out for your prototype, IMO.

Already tested. Now let me try with saving&restoring the
minibuffer-only frame; I can fall back to your proposal easily enough.

> If the value is a window then it supposedly must be a minibuffer
> window on some other frame.  How you would deal with that in the
> context of desktop.el I don't know. I guess if you are actually
> restoring windows in general then you could restore that value (and
> hence the association) as well.

That's currently not possible because we don't have a way to identify
a window (in the window state returned by window-state-get). Martin
said it could be added, if required, but let's try to avoid it if at
all possible.

> Every beast is a strange beast.  Every Emacs feature that one is not
> used to using seems strange at first.

You're talking about UI. I can understand why you do think that they
are not that strange (or stranger than any other setup). I was talking
about implementation. From a cursory look at frames.el and other code,
I'd say minibuffer-only frames add a lot of complexity.

> FWIW, a standalone minibuffer frame was not only not strange but was
> the DEFAULT and the TYPICAL way for users to interact with Emacs back
> in the days of Epoch.  And Epoch's standalone minibuffer worked even
> better than what I've been able to cobble together for GNU Emacs.

Individual tastes and diversity are wonderful things. From using
minibuffer-only frames for a few minutes, I wouldn't touch them with a
ten foot pole. Multi-frame setups yes, they are nice and, as Stephen
said, in many cases is easier to deal with many open frames than
switch between Emacs windows. But I fail entirely to see the appeal of
having the minibuffer in another frame. Which is not to say that I
won't work hard on make them work with this feature ;-)

> http://www.youtube.com/watch?v=Ku-ChVdBwDs
> [Louis Jouvet, "Drole de Drame", 1937]

Funny.

   Juanma