emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

desktop-restore-frames


From: Juanma Barranquero
Subject: desktop-restore-frames
Date: Mon, 15 Jul 2013 02:08:14 +0200

OK, I've just committed a change to desktop.el which enables
desktop-restore-frames by default.

At this point, the code is working well enough in my setup, which alas
is wholly Windows-specific. So it's time to let the little bird fly
and start receiving suggestions, feedback, bug reports and possibly
blunt force trauma.

* ADDED:

- Option restore-in-current-display now offers three possibilities: t,
which forces frames to the current display; nil, which allows each
frame to go to their display, and delete, which restores frames in the
current display and deletes others.

- New option desktop-restoring-reuses frames, with three possible
values: reuse existing frames (if possible, else delete them), delete
existing frames (and create new ones for saved frames), and keep the
existing ones (and restore saved frames in new ones).  A problem with
`keep' is that is more useful for M-x desktop-read than for the
initial read, because it does keep the initial frame, which is likely
not what the user wants. Workarounds include adding code in your
.emacs to delete that frame:

(setq *initial* (selected-frame))
(add-hook 'desktop-after-read-hook
          (lambda ()
            (when *initial*
              (ignore-errors (delete-frame *initial*))
              (setq *initial* nil))))

or adding a new option, if necessary.

- Support for minibuffer-only and minibufferless frames. In many
normal setups, saving & restoring these kind of frames should work as
expected.  I haven't added an option to skip restoring minibuffer-only
frames, as Drew suggested. Let's try this first and I can add it
afterwards if required.

- Workaround for bug/feature/infelicity#14795. Now frames should be
restored with the right height, regardless of their tool-bar-mode
setting.

- Vastly improved parameter filtering. It now allows setting filtering
functions to precisely determine when and how parameters are passed
untouched, removed or modified. As a corollary, fullscreen,
size/position and font parameters survive the tty roundtrip intact.


* NOT ADDED / FOR DISCUSSION:

- I have not made any attempt to detect off-screen frames and move
them back on-screen. As there are legitimate uses of off-screen
frames, we should discuss what is the expected UI before throwing code
at it.
- Currently, desktop-restore-frames is enabled by customize. In some
cases, it seems it would be useful to be able to easily enable/disable
it, either as an argument to desktop-save-mode or as a new
pseudo-minor-mode.
- M-x desktop-clear "cleans up" the desktop by removing buffers, etc.
Should that command also (directly or via an argument) remove windows
and/or frames? IMO both possibilities seem reasonable.
- All names are up for discussion, of course. I'm really bad at naming
functions and options. Also, suggestions to make docstrings clearer
are very welcome.
- Other than desktop-filter-parameters-alist, I have not added any
low-level hook to allow tinkerers to piggyback into the save&restore
mechanics. I suppose the existing hooks and advice-add should suffice,
but if someone has anything specific in mind that would require other
entry points, I'm all ears.
- Some of this stuff, once polished, should be documented in the elisp
or emacs manual. Not by me, though, sorry.


* THINGS KNOWN NOT TO WORK:

- Minibuffer(less|-only) frames do not survive the roundtrip to tty
and back. It could be made to work, but it is a bit complex and I'm
not sure how useful / necessary it really is.
- On Windows, invisible frames turn visible the second time they are
restored, as an interesting consequence of bug#14841.


* BADLY NEEDED TESTING:

- Non-Windows environments.
- Anything "multi": multiple displays, multiple monitors, complex
multi-frame setups, multiple terminals, etc.
- daemon mode.
- GUI and tty frames in the same session.

I think that's all.

Enjoy,

    Juanma



reply via email to

[Prev in Thread] Current Thread [Next in Thread]