RE: How to restore the layout?

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

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

I was talking only about a standalone minibuffer frame.  Sorry if that
was not clear.  How is it different?  In the ways I've already described,
i.e., the uses I described as being, I think, typical.

And in the fact that it uses `minibuffer-frame-alist', which supersedes
`default-frame-alist'.  IOW, almost the same answer for why we even have
a `minibuffer-frame-alist' user option.

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

In general, yes.  My assumption was that that is not generally the case
for a standalone minibuffer frame.  Whereas there can often be many
frames that are built off of the `default-frame-alist', and which a user
might well move here and there and resize, I don't see that kind of thing
happening typically for a minibuffer frame.

I'm not saying that what I think will be the typical case is the only
possible case.  I think I mentioned that a few times.  I can't really
speak much to such cases.  My experience is with the case I'm assuming
will be typical for someone using a standalone minibuffer.  Others are
free to correct me if they feel otherwise.

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

No, that would be independent of the considerations I put forth for the
minibuffer frame.  I see desktops used lots of different ways. 
A simple and common way will be to simply remember and restore the last
state of Emacs, including the sizes, positions, colors, fonts (yes,
fonts!), etc. of its frames.  I nevertheless see changes to the
minibuffer frame due to the dynamic use of Emacs to be something (a)
rare and (b) you probably do not want to save.

Since I mentioned fonts -

I think I saw that you mentioned that you cannot currently save/restore
a frame's font.  To me, that ability is far more important that letting
users record and restore any dynamic changes they might have made to a
standalone minibuffer frame.  It is important to me, at least.

For me, restoring a frame's font is also required for restoring
thumbnail frames.  They are, to simplify, tiny frames made tiny by
shrinking their fonts.  Of course, it is not just font size that
matters, but other aspects of the font as well.  I change various
fields (including size info) of an XLFD font name, and would expect
that to be restored by Desktop.

(I realize that not everything will be perfect in the first draft.
I'm just saying that, to me, restoring the font is important.)

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

See above.  Yes, that will a common use case, perhaps the most common.
Nothing I've said gets in the way of that use case, if you assume that
people will (a) not be dynamically changing a minibuffer frame and (b)
will not care to save any dynamic changes they might happen to make to
it.  (I'm not talking about changes to it that they might make through
customization etc., but simply moving or resizing etc.)

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

Where would you expect that you would be moving it, and why?  Again,
I'm not talking about customizing where you want it, and perhaps
changing your mind about that customization once in a while.

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

Let me be clear.  I have no problem with you doing what you suggest:
make a standalone minibuffer behave like others in terms of remembering
its state.  I was trying to make your job easier by pointing out that
in most cases no one need that feature.  But if it works well then I
have no problem with it.

Here's a probably lousy analogy, but it is one that comes to my mind:
The Windows task bar.  You can move it to the top, bottom, left or
right.  Most people do not move it every 30 minutes.  Moving it is,
effectively, customizing its position.  But yes, the fact that Windows
remembers the last position as the customization is fine.

I would have no problem if Desktop handled the minibuffer frame
similarly - modulo certain considerations (below).  I will go further:
if Desktop handles that right then it lets users not worry about setting
things up using Lisp code.  They can simply drag the frame to where they
want it and give it the size they want, and that will be remembered
(provided they start up with Desktop) each time.  Formidable!

But the devil will be in the details wrt "works well", probably.
My setup code creates a new minibuffer frame according to user
customizations.  If the desktop code can be used in such a way that it
does not interfere with that then there will be no problem.

You might want to reread what I wrote about the creation of a
minibuffer frame.  To have one, you need to create it during startup.
That means that users do so in their Emacs startup.  And there can be at
most one such frame.

If a user uses Desktop to restore the last state and that state now
tries to also restore a saved minibuffer frame, then that restoration
code needs to check whether there is already a minibuffer frame, and if
so then either (as I said before): (a) ignore its saved info for the
minibuffer frame (leave the user's frame alone) or (b) MODIFY the
already existing minibuffer frame - as opposed to trying to create
another such.

If you implement a way for a user to choose between (a) and (b), no
problem.  If you offer only (b) then that would be limiting for a
user who wants to control the frame properties via setup at start time.
If you offer only (a) then that would be limiting for the user who
really does want any last-session changes to the minibuffer frame to
be reflected in the new 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.

That is (b), above.  A user should have the choice.

In fact, now that I mention that -

Users use frames for different things.  A user might well have
particular other frames, besides the minibuffer, that s?he wants to
have defined each time based on a startup-time setup, i.e., that s?he
does not want to have changed by Desktop.

Conceivable, at least.  I don't use frames that way, but some people
might (I too can hypothesize ;-).

In my case, I use "special-display" to handle frames that I want to have
particular properties.  And since that is set up anew each session, and
since the properties are anyway frame parameters, I'm pretty sure that
Desktop will not be a problem for me here.

Nevertheless, yes, it would be good to have a general feature of
classifying particular frames off-limits for Desktop, i.e., frames that
it either would not record or (probably better) simply would not restore.
The latter would probably be better because we could provide a runtime
way to override this prohibition on Desktop, i.e., to let a user allow
Desktop to restore a particular frame classified generally as off-limits.

There are lots of possibilities.  I'd say handle the simple case(s) first.
And in my view, leaving the minibuffer frame alone is the simple (common)
case.  IOW, if you have a minibuffer frame then I think you probably want
it in the same place each time.  Again, someone will correct me if they
think otherwise.

And again, if you can make it work well and be flexible  then it would be
an advantage to be able to directly manipulate the frame into the size and
position that one wants to keep.  Desktop could perhaps help there, but
I would rather see such direct-manipulation translated into customization.
IOW, once you get something like a minibuffer frame the way you generally
want it, you want to be able to say Basta! Hands off from now on, until I
change my mind.

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

It wouldn't be possible, AFAIK.  What would happen is (likely) what we
saw: only one of the frames would get the `only' value of parameter
`minibuffer'.

But I think we are really saying the same thing here, describing it
differently.  We don't want two frames trying or pretending to each be
the minibuffer frame, even if only one can ever really be such.

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

Yes.

> And I was talking about kill-emacs / run emacs.

Meme combat - from my point of view.  Not the same use case, but I feel
the same about both cases.

> A new minibuffer-only frame is created.

But, as I mentioned, since a minibuffer frame must be created during
startup, it will be created (anyway) by the user's startup code.

Now just maybe, if you make Desktop get in the act and try to restore
the minibuffer frame, the user will then need to start worrying about
just when to invoke Desktop, relative to the user code that creates the
minibuffer frame.  Or maybe s?he will now have to worry about having
conditional code that checks whether desktop (which might have run first)
has already created a standalone minibuffer, and then skip doing that
in the user startup code.

IOW, either Desktop or the user will need to worry about avoiding an
attempt to create a second minibuffer frame.  I would rather it be
Desktop, a priori.  See above for possible extensions to allow users
to let Desktop restore (i.e., create or modify) a minibuffer frame.

But the default Desktop behavior should, IMO, be the simple one (from
a user point of view): YAGNI, i.e., Desktop hands off the minibuffer.

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

I agree.  That's why I said "for a while".  There is also a risk of
boring others and going down a rabbit hole.  My suggestion was to
get through the vague discussion part using simple recipes instead,
then report back and get more input/discussion.  But I'm OK with either
way, as I've shown by this message. ;-)

> Surely you're not the only one using multi-frame setups and
> minibuffer-only frames :-)

I would hope not.  But I would unfortunately be willing to bet that
among those reading emacs-devel we are not a multitude. ;-)

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

Not to worry. ;-)

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

+1 to that.

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

There is more locality, not less.  Not in the sense that the minibuffer
is always closer to the particular buffer text you're editing/reading, but
in the sense that the focus stays the same for command I/O.

I probably spend a lot more time in the minibuffer than most.  But what
I do there involves interactions with other frames - in particular a
standalone *Completions* frame.  If the minibuffer and *Completions* buffer
were jumping all around from frame to frame it would be very distracting.

But as you noted, everyone is different.  After I tried Epoch (with its
standalone minibuffer) a couple of decades ago, I never went back, even
though it was a hassle to wrestle GNU Emacs into doing something similar.

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

Height, but not width.  When I said "long" I meant "wide".  Being part of
an ordinary frame, your minibuffer cannot be screen-wide, unless the
frame is too.

I decouple the width I need for (a) a given frame, which is typically
the width of its text, which is typically of a fixed line length
(different for different kinds of buffers, of course) from (b) the width
of my minibuffer.

There is no logical relation between the width (I still want to say
"length", when talking about line length) of (a) minibuffer input and
echo area output and (b) ordinary buffer text.  Just as I want to fit
most frames to their (typically single) buffer text, so I want to have
a minibuffer that is not limited to the width of any other buffer's
text or window.  Why should it be?

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

Si.