RE: How to restore the layout?

[Drew Adams]

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

"Already" when? You mean before restoring a desktop?  If so, agreed.

That was my point, wrt the minibuffer frame: a user will already have it
set up, before trying to restore a desktop.

> 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

Restore when?

> at the new position, not the one in initial-frame-alist.

Sorry, I don't follow you.  Restore how - via a desktop?

I don't see `initial-frame-alist' entering the discussion anyway, but that
might be because I don't make any use of it.  I use only `default-frame-alist'.

I guess if I wanted to see the initial frame with different properties from
`default-frame-alist' then I would do something like this:

(setq default-frame-alist nil
      initial-frame-alist '((background-color . "Whatever")))
      default-frame-alist <whatever I wanted different>)

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

It's not clear to me what you mean by restoring, or when that happens.

Typically, a user with a standalone minibuffer will (must?) set it up when 
Emacs starts, from the command line or the init file.  If s?he then moves that 
frame
for some reason, I would NOT assume that s?he wants the next Emacs session to
remember the last position/size of that frame.  I would assume that the same
startup code would be used to configure the frame anew the same way.

IOW, I would assume that if a user wants to change what the standalone 
minibuffer
frame looks like, s?he would do that in the startup code.

Perhaps you are suggesting something like this: A user might want different
desktops that have different standalone minibuffer properties (e.g. size, 
position).

If so, yes, I can see that possibility.  But I would advise leaving handling
that possibility for later, as it's not obvious in that case how to deal with
the various problems I reported to you (separately).  There needs to be (IMO,
AFAIK) at most one standalone minibuffer.

Perhaps one solution would be to go ahead and (as you have done so far, I
believe) record the standalone minibuffer frame, but when it comes to restoring
from a desktop, do NOT try to restore it if there already is a standalone
minibuffer frame.

Or perhaps, if there is already a minibuffer frame, just MODIFY its parameters
based on the recorded ones from the desktop - as opposed to creating a new
minibuffer frame.

In any case, I think you need to avoid trying to create another minibuffer 
frame.
And avoiding that might just eliminate some of the problems I saw.  (Dunno.)

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

What "new minibuffer frame"?  My suggestion was to NOT record or restore
a minibuffer frame.  So restoring a desktop should not be creating any "new
minibuffer frame".

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

It's hard to talk about this and follow each other, with just descriptions.
I suggest we take it off list for a while and we stick to easy-to-follow
recipes.

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

I'd suggest that we start with that.  See my other suggestions above, for
possible use afterward.  IOW, we might be able to (optionally) accommodate
save/restore of a minibuffer-only frame, if the restore operation avoided
trying to create a new standalone minibuffer frame when one already exists.

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

Great.  Good to hear that at least the simple solution works.  (That should
be enough for my own use.)

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

I see.  Yes, I mistakenly thought you were talking about a user point of view.

> 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 ;-)

Thanks for the last part. ;-)

As to the missing appeal:

1. Single place to look for all user command input and echoed messages.
   No matter what frame might be selected, your visual focus for commands and
   messages is always the same.

2. Long, long minibuffer - full-screen width.
   And in my case, expands to any number of lines.  (I use the minibuffer for
   lots of stuff, including sometimes large sexps.)

3. Less wasted screen real estate.  This (minor) advantage would go away
   if Emacs showed a minibuffer only for the selected frame.  No need for each
   frame to show a minibuffer/echo area, even if it cannot currently be used.

   However, if Emacs did dynamicaly show/hide minibuffers in frames that way,
   it might be distracting/disorienting.  In any case, I would prefer the
   single-location, permanent, standalone minibuffer frame solution.