Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jul 2, 2013 at 5:46 AM, Drew Adams <address@hidden> wrote:

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

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

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

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

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

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

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

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

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

=>

(only only only only only #<window 03599398 on  *Minibuf-0*>)

> (visibility . icon) does not affect the test, is just to avoid cluttering my 
> desktop.
> 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.

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

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

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


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

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

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

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

> I agree.  That's why I said "for a while".  There is also a risk of
> boring others and going down a rabbit hole.

You mean they aren't already there, hidding from us?

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

> Height, but not width.  When I said "long" I meant "wide".

Ah, interesting. Yes, I can see the appeal of that.

   J