RE: How to restore the layout?

[Drew Adams <drew.adams@oracle.com>]

> > Another possibility/suggestion, from little-to-no knowledge of this
> > stuff: Simply do not record or restore a minibuffer-only frame.
> 
> Yes, that's one posibility, but then, if the user moved or resized it,
> these changes won't be restored. Not a deal breaker, but something to
> take into account.

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.

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.

This assumes that everything works as expected otherwise:

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.

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.

If I prove wrong about the expected use cases then you can think later
about providing a user option.  The default behavior should anyway,
IMO, be what I described: do not record or restore any frame that has
`only' as its `minibuffer' frame parameter value.

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

> OTOH, restoring a minibuffer-only frame does not
> really make much sense unless you do it first of all and set
> default-minibuffer-frame to it...  Time to go doing some
> experimenting.

Exactly.

> > Otherwise, record the `minibuffer' property of a frame, including the
> > case where it is nil (no minibuffer).
> 
> The `minibuffer' property can contain non-readable things, like a
> window reference.

Yes.  I don't know whether anyone uses that, or whether it is used
somehow internally by Emacs.  In any case, I have nothing useful to
offer about that.

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.

But again, what is a use case for that?  It would not be needed for
the usual case of input redirection, AFAIK.  For that, you would just
redirect input to your standalone minibuffer.  (That's what I do for
a separate *Completions* frame, for instance.)

> > (But from your message I now have a doubt: is it necessary to
> > associate the ordinary restored frames with the existing standalone
> > minibuffer?)
> 
> minibuffer can be t/n/only, but also a reference to a minibuffer
> window in another frame.
> - t : nothing to do, it works out of the box
> - nil: emacs will try to associate the frame with
> default-minibuffer-frame or create one minibuffer frame for it
> - only: as discussed above
> - a window: we currently can do nothing about this, because we do not
> have a way to name windows and restore references to them.

See above.  I wouldn't worry about the window-valued case, at least
for now.  Note too: it is not just any old window - it should (must?)
be a minibuffer window.

> > Keep in mind that to use a standalone minibuffer you really need to
> > set it up at startup time, e.g., from the command line or from your
> > init file.  You cannot add a (useful) standalone minibuffer after Emacs
> > has already created its first frame, which has its own minibuffer.
> 
> Yes. minibuffer-only frames and their brethren are strange beasts.

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

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.

From http://tonic.physics.sunysb.edu/docs/emacs/emacsFAQ.html#sec93
(long ago):

  93:  What is the difference between GNU Emacs and Epoch?
  
  Marc Andreessen <marca@ncsa.uiuc.edu> writes:
  
    Epoch is GNU Emacs on steroids: an adaptation of GNU Emacs with lots of
    additional support for features made possible by the X11 windowing
    system.  These features include multiple editing windows, arbitrary
    colors and fonts (fixed-width and proportional), selectable zones per
    buffer with arbitrary display styles (font, color, underline, stipple,
    pixmap), an optional separate minibuffer window, improved keyboard and
    mouse handling, full 8-bit character set support, and more.

From http://www.cs.utah.edu/dept/old/texinfo/epoch/epoch.html#SEC9:

  Epoch supports two different kinds of minibuffers. The default is a
  non-local minibuffer, which is displayed in its own distinct screen;
  this is what Epoch has traditionally done. The alternative is to have
  minibuffer windows local to each edit screen; this is similar to
  traditional GNU Emacs. In the case of non-local minibuffers, there
  will always be exactly one minibuffer screen, and one or more edit
  screens; a single edit screen and minibuffer screen together act
  similarly to normal GNU Emacs. For local minibuffers, the real
  minibuffer will be located at the bottom of the current edit screen. 

Yes, GNU Emacs has caught up with much of what Epoch offered more than
20 years ago.  And it has added important features that Epoch did not have.
But in spite of being the best thing around today, GNU Emacs has still not
caught up with some of what Epoch offered, out of the box, many, many moon
ago.

Strange?

  "Bizarre" ? Moi, j'ai dit "bizarre, bizarre" ? Comme c'est drole.
  Pourquoi aurais-je dit "bizarre, bizarre" ? ... Moi, j'ai dit
  "bizarre" ? Comme c'est bizarre.

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

Longer extract (3.5 min):
http://www.youtube.com/watch?v=4QiuzDEWD8I