RE: Window configurations

[Drew Adams]

> >> Could we add as an extra `buffer-file-name' alist element
> >> in the sexp of a window-configuration or is that a bad idea?
> >> (I was just tring to reconstruct a window-configuration
> >> after an emacs reboot but quickly found out filenames
> >> weren't just there.)
> >
> > For saving/restoring, we'll probably need to save the same info used
> > by bookmark.el or desktop.el (unifying the two might also be a good
> > idea, BTW).
> 
> Since bookmark.el is conceptually more low-level than desktop.el,
> the latter could use a subset of services provided by bookmarks.
> 
> There is one problem of using bookmark records for desktop.el.
> Some bookmarks take too much time to restore when reading 
> from the desktop file.  So packages will need to distinguish
> between making a bookmark for bookmark.el or desktop.el to not
> save some bookmarks in the desktop file. Maybe
> `bookmark-make-record-function' will require a new argument for that.

Sigh. I really wish you guys wouldn't mess with this. Put what you want in a
window config, but please do not try "unifying" bookmarks and desktops (and
window configs).

If anything, bookmarks are more general and higher-level (not lower-level) than
desktops. Why? Because you can save/restore many different types of things as
bookmarks, each in its own way. Each can have its own handler.

Anything can be bookmarked. A desktop records one type of thing: a desktop, no
matter what you might want to stuff into a desktop, no matter how complex it is.

If you want to add handlers or other bells and whistles to desktops, go for it,
but please do not try to merge bookmarks and desktops as if they were the same
thing or one were an instance or a subset of the other. They both record state
persistently and restore it; that's all. There is no reason to confuse the
concepts or merge the code.

On the other hand, a desktop can be targeted as one kind of bookmark - a
bookmark can restore a desktop just as it can restore an Info node. That is the
case in bookmark+.el, for example. But it does not make sense to record all of
the info for a desktop directly in the bookmark (and thus in a bookmark file,
which can contain _lots_ of bookmarks).

What makes sense is for a desktop bookmark to simply refer to a particular
desktop file, which records the desktop info. Likewise, for a window-config
bookmark. (I'm still hoping you will not hard-couple window-configs and desktops
- each can be used independently of the other, as well as together.)

Nor does it make much sense to add bookmark records to a desktop file. I don't
know what kind of bookmark "info" or bookmark "services" you think would be
required by desktops. Do you plan on adding handlers to desktops? Whatever. Add
whatever you must to window-config records or desktop records, but please keep
bookmarks separate from them both.

Keep things simple and separate, so users and programmers can easily combine
them at will in various ways. Just give us a way to save and restore window
configs, and we can always combine that (or not) with saving and restoring
desktops. And we can always create a bookmark to either.

Please do not start "unifying" everything into one big ball of knots.

Wrt generalizing and improving _bookmarking_, which is a different topic from
making window configs persistent and restorable, see bookmark+.el. All of that
improvement could be added to Emacs, as a patch to bookmark.el. (No, I don't
want to argue about it. If you don't want it, that's fine.)
http://www.emacswiki.org/emacs/BookmarkPlus

Bookmarking is about saving and restoring something - anything. It is therefore
about handling different kinds of stateful things differently. To improve
bookmarking, work on making it easy for users to distinguish and access the
various types, provide type-specific UI features and help, and so on.

Forget about constructing the uber unifying
bookmark-cum-desktop-cum-window-config cathedral. Please. The goal should be
separate Lego blocks of different shapes that fit together, not a big wad of
fused plastic.