RE: How to restore the layout?

[Drew Adams]

> > 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.
> 
> I disagree about "typical" here. The alternate use case I'm suggesting
> is neither convoluted nor artificial.

1. I was quite clear that it is just a guess on my part wrt the typical
or common use case for a minibuffer frame.  I gave reasons why I think
this might be likely, including the fact that to have such a frame a
user must set it up during startup, and `minibuffer-frame-alist' is a
customization.

2. No one has said that anything you have suggested is convoluted or
artificial.  I don't even think that, let alone have not said it.

> > 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.
> 
> Well, the initial frame also has a `initial-frame-alist' that
> supersedes `default-frame-alist', but you're not proposing to treat it
> different that other (non-minibuffer-only) frames.

I'm no expert on any of this stuff, but certainly not about
`initial-frame-alist'.  Its doc string, like that of `minibuffer-frame-alist',
says that it "supersedes" `default-frame-alist', without saying what that
means.

What I said about `m-f-alist' is based on my experience with it.  I have
almost no experience with `i-f-a'.  If you feel it should be handled the
same as is `m-f-a', give that a try.

> > 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.
> 
> My assumption is that, just as `initial-frame-alist' is a template for
> the first frame (but changes are persistently saved by
> desktop-reuse-frames), `minbuffer-frame-alist' is a template for the
> minibuffer-only frame, but once created, the user is free to change it
> (and expect these changes to stick).

We have different assumptions wrt the typical use of `m-f-alist'.

Yes, anyone is free to change properties of the minibuffer frame after it
is created.  So what?  It does not follow that everyone or most will want
Desktop to save and restore such changes.  Time will tell, I guess.

Here's another data point you might consider: AFAIK, Desktop will save and
restore frame parameters, but those parameter values at any time do not
necessarily specify the frame completely from a user point of view.

What do I mean by that?

In oneonone.el, for example, the position and size of the minibuffer frame
is customizable.  But generally I recommend that absolute values not be 
used for this and that users instead let the code determine the width and
necessary `top' value to position the frame across the full screen width
at screen bottom.

That way, the frame is created correctly regardless of what screen you
view it on: laptop, large monitor, remote VNC window mgr...

IOW, whereas what frame parameters record are literal values, what a user
might want to express in some cases can be a behavior that does not reduce
to a literal value.  In Lisp terms, if frame paramters included functional
values then we might be talking apples & apples, but until then we are
talking apples & oranges.

Note that the recently added `fullscreen' parameter values are similar
to specifying functional behavior: they do not specify frame boundaries
explicitly but record the user wish that the frame fill the full screen
or whatever.  The implementation presumably leaves it up to the window
mgr to implement that function, and one cannot specify an arbitrary
function, but the idea is a bit similar: we do not record literal frame
coordinates & boundaries for a fullscreen frame.

If useful or common values (symbols) were implemented to encompass the
idea of a minibuffer frame extending across the screen bottom then one
would not need code to do that using code.  Until then, simply
recording and playing back frame parameters will not accomplish the
same thing.

It's just an example.

> > 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.
> 
> That's the point where we disagree. That said, you have much more
> experience with minibuffer-only frames than me. It'd be good if other
> minibuffer-only-frame users would speak now.

I have experience only in a limited range.  I've made Emacs do more or
less what I want; that's all.  I can't speak to what others might want.

But I would point to the experience of lots of people with Epoch, back
in the day - FWIW.  As I mentioned, a standalone minibuffer was optional,
but it was the default.  I never saw anyone who chose not to use it (and
I saw lots of people using Epoch).  And the frame was at the bottom,
stretching the full screen width (IIRC, and I think I do).

So my own setup is so particular, it is copied from something that
lots of people used to use.  Yes, GNU Emacs has taken over the landscape,
but that was not because of Epoch's standalone minibuffer.  FWIW.

> > 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.
> 
> Not saving the font parameter right now is not a decision or a
> feature, just a stopgap measure. Eventually I'll have to revamp the
> whole "save/restore frame parameters" code to allow more flexibility,
> and then I'll re-save font.

Sounds good.  That was my guess, that this is just something that you
cannot implement immediately, for whatever reasons.  Nothing wrong with
that.  It is wonderful that you are working on this general enhancement
to 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.)
> 
> Yes, agreed.
> 
> > 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.
> 
> In my tests of the minibuffer-only frame (MOF from now on), I like to
> have it near the main, or only, frame. So if I move the frame aside,
> because I want to see something that's below it (let's say I'm typing
> something related to something I'm reading in a browser tab), I
> immediately move the MOF too. I suppose that's uncommon for you
> because you put the MOF at a fixed place in the screen, likely not
> overlapping or overlapped with any other application's window. That's
> not how I work, I have Chrome open all the time, and it uses perhaps
> 80% of my screen space, so other things, including Emacs, do overlap
> it. Moving Emacs aside is a pretty common operation for me.

Got it.  I could be wrong, but I'd suggest using it for a month and then
see what you think.  Not joking.  I don't pretend to have discovered the
only way of working with frames - far from it.  But I have a right to
guess. ;-)

> > 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.
> 
> "Works well" is not how I would define it right now. "Works most of
> the time" is more like it, but of course, that difference is quite
> important. So I don't reject at all the idea of falling back into the
> do-not-save-MOF implementation strategy; I'm just wasting a little
> time trying alternatives.

That's good to do, and not a waste, no doubt.

> > 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.
> 
> Nothing overlaps with my Windows taskbar, so I don't need to move it
> anywhere.

Things don't overlap my MF, unless I put them there (e.g., make something
fullscreen).  But I do hear what you are saying (and I did say it was a
lousy analogy - if it doesn't help, ignore it).
 
> > 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!
> 
> That's what I'm trying to do.

Great.
 
> > 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.
> 
> Not exactly, though it will likely not work as expected:
> 
> (progn
>    (dotimes (i 5) (make-frame '((minibuffer . only) (visibility . icon))))
>    (mapcar (lambda (f) (frame-parameter f 'minibuffer)) (frame-list)))

OK.

> > 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.
> 
> Not really. She could use desktop-after-read-hook to reapply settings,
> for example. Some things we should allow via customization options,
> some others via hooks, etc. It is too soon to decide which one belongs
> to each category, I think. And customization options can always be
> added later as needed.

Sounds like trying to make a virtue of the necessity of a particular
implementation.  I sincerely hope that you allow for both (a) and (b)
and give users a choice.

> > 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.
> 
> Yes. Currently there's no hook run just before saving the frames and
> buffers, but I will have to add one.

In general, I would suggest saving stuff but letting restoration ignore
some of it, according to user preference etc.  IOW, it seems like it
would be more flexible to save and optionally not restore than to
optionally not save (and then not have the possibility of restoring).

This is assuming other things are equal, which they might not be.
But if they are, then late binding here is better: let the decision
be made at the next session.

What I said earlier about use with different monitors applies here as
well.  Your next session might be with a different monitor or on a
different platform.  Users might use desktop files across different
platforms, equipment/media, whatever.  You can easily do that now,
using desktop bookmarks, for instance.  As a general rule, it is
more flexible to let the consuming software/session decide, not the
producing software/session.

Again, assuming other things are equal, which you can judge better
than I.

> A practical example where I need
> it: I very often have IELM buffers open. IELM is the kind of buffer
> that does not make real sense to save&restore, because its usefulness
> often depends on its state (variables changed, commands typed, etc.).
> So I add it to desktop-buffers-not-to-save or
> desktop-modes-not-to-save... But window-state-put will restore the
> "buffer", if empty and in fundamental-mode. So I really need to be
> able to run a hook before desktop--save-frames which runs
> (delete-windows-on (get-buffer "*ielm*") 'all).

Or accomplish the same end some other way.  Worth thinking about.

> > 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.
> 
> Also called M-: (insert (format "(setq minibuffer-frame-alist '%S)"
> (frame-parameters default-minibuffer-frame))) <RET> plus deleting the
> MOF.plus some hand-tweaking. ;-)

Hopefully accomplish the same end another way.  This is something users
should be able to do easily.

> > But, as I mentioned, since a minibuffer frame must be created during
> > startup
> 
> That's not really correct. You can do, at any point in time:
> 
> (let ((f (make-frame '((minibuffer . only)
>       (height . 2)
>       (tool-bar-lines .0)
>       (menu-bar-lines . 0)))))
>   (make-frame `((minibuffer . ,(minibuffer-window f)))))

AFAIK, you will never be able to get rid of the frame created initially,
which has its own minibuffer.  That was the point here.  If you want a
standalone minibuffer frame, and if you want it to be the only such
(which I would again argue is the typical case of MF users), then AFAIK
you must create the MF at the outset.

Believe me, I've submitted enough bug reports for which I had to point
out a startup sequence, because adding a standalone minibuffer frame
later does not give you the same behavior.

> > 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.
> 
> M-x report-emacs-bug <RET>

Better to think about some of these things ahead of time.  Sounds like
you're thinking more in terms of hooks to dance around Desktop than
customization options to prevent it from doing the things you would have
users dance around.  I could be wrong but that's my impression based on
some of what you wrote above.  I would sooner you implemented (a) and
(b) above, and let users choose.

> > 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.
> 
> At some point, for some combination of user customizations and use
> cases, the user will have to resort to worring and checking and
> configuring via hooks. I wouldn't have ~2,000 lines in my .emacs if
> that were not the case.

Or decide it's not worth it and not use Desktop to restore frames.

I hope, at least, that users will be able to use Desktop without the
frame/window restoration.  And I hope they will be able to restore
windows & frames without necessarily restoring all the other stuff
that Desktop can handle.

IOW, I hope we give users control over the various things that Desktop
can save & restore.  And I hope that control will be available both in
terms of saving (don't bother saving stuff you know you don't want to
restore) and in terms of restoring (save, but do not restore if told not
to - see above for the flexibility this offers, at a cost of
save/restore time and desktop-file storage space).

> > 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.
> 
> My "simple behavior" would be: do not treat the MOF differently than
> any other frame. :-)

Which is why I wrote "from a user point of view".  I'm not interested
here with simplicity of implementation.  Of course, we can disagree about
what is simpler for a user.  Again, I'd point to Epoch users...

> > 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
> 
> That's locality for me (or at least, for my visual cortex).

But you're not necessarily acting on or interacting with a single buffer
or frame, in general.

That's another difference I didn't mention.  I use the minibuffer more,
but I also use it to act on multiple buffers and frames during the same
minibuffer "session" (the command calling for minibuffer input, completion
in particular).  When using the minibuffer, even when my eye is not on
the minibuffer and not on *Completions*, it can easily move among multiple 
frames/buffers.  In this context, the most central, static, or "local"
location during the interaction is the minibuffer - it is the center of
the action.

I'm not saying that anyone needs to use a standalone minibuffer. 
I'm saying that someone who does do that has a single place to look
for command input/output.

You said:

> In my tests of the minibuffer-only frame (MOF from now on), I like to
> have it near the main, or only, frame.

Wait until you are interacting with multiple frames, and there is NO
"main, or only, frame".  Then we can talk again about "locality". ;-)

> > Height, but not width.  When I said "long" I meant "wide".
> 
> Ah, interesting. Yes, I can see the appeal of that.

Cheers - and thanks again for working on this.  It will be a welcome
addition to Emacs.