Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 4:08 PM, Drew Adams <address@hidden> wrote:

> I'm not familiar with the code, but a priori it feels like that should
> be doable and done at the outset.  Is there some reason it would be hard
> to stop Desktop from saving (or restoring) the other stuff?  I'm not
> asking you to go into detail here, just wondering what the difficulty is
> in general terms.

The "other stuff" is buffers (and a few global variables, but that's
almost irrelevant). window-state depends on buffers. Of course it is
already possible to restore a window and find that its buffer is
missing (currently, I think the end result is that the buffer will be
recreated in fundamental mode). But it does not make much sense not to
save buffers but do save frames and windows, unless and until we
define an UI to allow the user to more precisely explain what does she
want to save and what doesn't want to.

Which seems useful, but not something I'm going to worry about right now.

> IOW, why argue that people with standalone minibuffer frames lose locality
> if the supporting case is a single frame scenario?  Sounds a bit like
> saying that a teaspoon is not the best pot for boiling lots of water.

I've never argued that standalone minibuffer frames lose locality.
I've argued that they lose it for me. They are farther, and in the few
cases that I use two or more frames, more so.

> OK.  But I thought we were discussing the "locality" argument you raised
> generally.

No. Of course no. That's why I've mentioned my problems with
recentering scrolling. I do know it's not a general problem, because
many users enjoy recentering scrolling, which to me is so incredibly
annoying that I would literally be unable to use Emacs if I weren't
able to customize away that "feature". In the same vein, many people
find useful to have things at the same location in the screen (that's
why the taskbar does exist, after all).

   J