Re: How to restore the layout?

[Juanma Barranquero <lekktu@gmail.com>]

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

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

Yes. in the init file, or via X resources / W32 registry.

> Restore when?

In all this discussion, when I say "restore" I'm mostly talking about
automatic (desktop) restoration while starting emacs, but I don't
think a later M-x desktop-read <RET> would be any different.

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

Yes.

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

That doesn't really change much of what is being discussed.

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

That's weird. If I set up default-frame-alist to create frames of size
80x50, and then I resize them, after desktop-save/desktop-read (or
exit Emacs and restart it) I would expect them to be just like I left
them, not how the "code to configure the frame[s] anew" would make
them. That's the *whole* reason I'm using desktop-restore-frames. I
assume you would expect the same. How is the minibuffer-only frame any
different?

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

Yes, for new minibuffer frames. But when you're using
desktop-restore-frames, you're asking your frames, and the changes (in
size, position, window setup and buffers displayed) to be
persistent...

Hmm. While writing the above sentences, it dawned on me: it seems like
you're thinking of desktop-restore-frames as a way to set
(quasi-)immutable snapshots (or desktop bookmarks). You want to use
them to be able to roll back to defined window&frame states. Is that
so?

That is, of course, perfectly valid, but desktop-restore-frames must
also support a more transient use case, where what the user wants is
for the current state to be saved upon exit and restored on restart.
If I were to use a separate minibuffer-only frame, my expectation
would definitely not be for that frame to appear always at the sample
place, but at the place it was when I exited from Emacs. To me, that's
not a new frame recreated anew in each Emacs run (though it really is,
from Emacs' POV); it's the same one I moved aside or resized in my
previous working session.

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

That's more or less what I'm trying right now.

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

Yes, agreed. Creating a second minibuffer-only frame would be a bug.

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

I think you're talking about a desktop-save/desktop-read use case:
that is, you say that if you have a current setup, with a
minibuffer-only frame, and you do M-x desktop-read, no new
minibuffer-only frame should be created. And I was talking about
kill-emacs / run emacs. A new minibuffer-only frame is created.

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

OK, though public discussion helps to integrate other people's
opinions. Surely you're not the only one using multi-frame setups and
minibuffer-only frames :-)

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

Of course, that's always been the goal. Let's not forget that we're
talking about unfinished code and evolving designs here.

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

Yes, though it wouldn't be for mine, if I used a setup like yours. Now
would be a great time for different opinions to enter the discussion
(hint, hint).

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

In my case, that would be a disadvantage, when using multiple frames
(for a one-work-frame, one-minibuffer-frame, I could bear it, though
it wouldn't really be much different or better than the default
setup). Non-locality kills me. That's the same reason, I suppose, I
can not stand the recentering scrolling of stock Emacs and must resort
to line-by-line scrolling.

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

You don't need minibuffer-only frames for that. I have my minibuffer
set up so it can grow up to 1/3 of the frame height, which I find more
than enough for most uses. You could potentially make it almost
full-screen height.

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

Goes to show why both of us use the Extensible, Customizable Text Editor.

   J