Re: Window configurations

[martin rudalics <rudalics@gmx.at>]

 > The point of set-window-configuration-from-sexp is to restore the
 > configuration of windows, not to duplicate the functionality of desktop.el.

That's true from a theoretical point of view.  It separates concerns in
a clear way and gives clean semantics.  Hence I fully agree with you.

Unfortunately, in personal practice, I'm suffering from a quite similar
problem.  In particular, I display eldoc output on a per-window basis in
a one-line window below the code window (I hate eldoc output in the echo
area, I don't like it in the header line, and I very much hate tooltips.
Ideally, there would be a bottom-line right above the mode-line where I
could put it, but ...).

Now I'm killing such an eldoc-buffer as soon as it is no more shown in
its eldoc-window.  But when (1) a `save-window-excursion' restores the
saved configuration and (2) it has to restore a former eldoc-window that
was deleted within the body of `save-window-excursion', I get the first
buffer from `buffer-list' shown in that window which is downright silly.

I solved my problem by killing such stale eldoc-windows after the
configuration gets restored in a `window-configuration-change-hook'.
This is, however, a slight redisplay pain, in particular with such
niceties as (save-window-excursion (info)) in `info-lookup'.  I maybe
could come up with a satisfactory solution, but deleting and creating
windows in `window-configuration-change-hook' is error-prone :-(

So if we could hook into this in some way, for example by providing a
window parameter that tells `set-window-configuration(-from-sexp)' what
to do if the buffer no longer exists, that might not be a bad idea.

If the buffer had a `buffer-file-name', we could try to regenerate it
automatically from that name.  If the file was deleted in the meantime
(or is remote or hard to find), some warning message could be displayed
in a temporary buffer in the restored window.  Looking up a file via
bookmarks could happen here as well.

If the buffer was not associated with a file, we could try to regenerate
it based on the old name stored in the parameter.  For killed *info* and
*help* buffers probably more information would be required.  All this
would happen independently from desktop.el in the session version and in
the sexp version.

And, as noted above, this idea is not based on clean semantics but on
running into practical issues.

martin