Re: How to restore the layout?

[Juanma Barranquero <lekktu@gmail.com>]

On Tue, Jul 2, 2013 at 9:40 PM, Drew Adams <drew.adams@oracle.com> wrote:

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

Please, don't take my comment as more than it was, just that I thought
that my use case is equally common. Wasn't accusing you of anything.
:-)

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

Sure.

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

I agree that ways of specifying more generic behavior would be good.

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

For the "across the screen" bit you can of course use (fullscreen .
fullwidth), though I see an interesting bug where the frame does not
really goes fullwidth until selected. But for positioning it at the
bottom, (top - N) is only a crude tool that requires some code.

> Yes, GNU Emacs has taken over the landscape,
> but that was not because of Epoch's standalone minibuffer.  FWIW.

I'm sure of that ;-)

> Sounds good.  That was my guess, that this is just something that you
> cannot implement immediately, for whatever reasons.

Because it breaks restoring after the roundtrip GUI -> tty -> GUI. But
it is something I must fix, like the warning messages in that same
roundtrip about invalid colors.

> Sounds like trying to make a virtue of the necessity of a particular
> implementation.

No, I'm not. Just that I can see many things that could be
customizable (via defcustom, I mean) but I don't think all should be;
only the common ones. At the end, which ones do get their own
customization option and which ones do not is not mine (alone) to
decide, it's a community thing (and of course, anyone can add further
options afterwards even if they didn't strike me as necessary).

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

In general, I agree.

As for the devil in the details: there are things that make sense to
delete on saving (like unwanted windows). And in some cases, the code
is cleaner if you delete on saving. desktop--restore-frames is already
more complex than desktop--save-frames, and I don't think that trend
will change.

Something to decide feature by feature.

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

Yes, of course. Perhaps killing some windows/buffers will be a common
enough operation that some defcustom should be added, for example.

In fact, the example I gave is tricky, because I don't want to delete
IELM windows while I'm working (for example, if I do M-x desktop-save
during a session). So perhaps that's one of these cases where deleting
on restoring is more effective and simple.

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

I'm not sure what the UI would be for that.

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

Yes, you can delete the initial frame, just try this:

(let* ((s (selected-frame))
       (f (make-frame '((minibuffer . only)
                        (height . 2)
                        (tool-bar-lines .0)
                        (menu-bar-lines . 0)))))
  (make-frame `((minibuffer . ,(minibuffer-window f))))
  (delete-frame s))

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

Oh, I think the minibuffer should give the same behavior, but I have
not trouble believing you that it doesn't. Lots of tricky details.

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

As said above, it's not that I think that, it's that the number of
possible customizations is unbounded, while the number of defcustoms
we can sensibly add is bounded and relatively small, so we have to
pick our battles.

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

That's a possibility I cannot avoid in any way.

> I hope, at least, that users will be able to use Desktop without the
> frame/window restoration.

(setq desktop-restore-frames nil)

Or, if I we decide to turn it into a pseudo-minor mode, like
desktop-save-mode, (desktop-restore-frames -1).

> And I hope they will be able to restore
> windows & frames without necessarily restoring all the other stuff
> that Desktop can handle.

As discussed previously, that's a worthwhile goal, but not one I'm
pursuing right now.

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

*In general*, yes, I do. If not a single buffer, at least a single
window, two at most, more than 99% of the time. And definitely a
single frame.

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

Yes, of course. At this point, I'm just explaining why do I think that
it isn't a good setup *for me*.

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

My brain is wired to look at nearby places, not always at the same
place. Again, that's why recentering scrolling doesn't work for me. I
could put my eyes in the center line of the window and enjoy the
recentering, but I do not. I really do not.

    J