Re: emacs commands / emacs windows / coordination

[Miles Bader]

Eli Zaretskii <address@hidden> writes:
> In what sense does save-window-excursion ill-suited for Lisp programs 
> that don't use recursive edit?  I don't see any such considerations in 
> the ELisp manual, and some Lisp packages do use it without a recursive 
> edit.

save-window-excursion save the window state while a piece of code
excutes, and restores it after the code is done.  If user-interaction is
involved, then a recursive edit must be used.  In many cases, this is
done by reading input with the minibuffer, not by using the
`recursive-edit' function.

Commands such as the vc checkin command, on the other hand, pop up a
buffer for the user to edit, and then return to the top-level
interaction loop; any further progress is (typically) done by the user
invoking a special command in the buffer that was popped up.
save-window-excursion cannot be used in this case.

> > I think Joachim's idea -- to pop up windows by splitting the current
> > window, so that deleting it restores the old state -- is interesting,
> > at least for those users that tend to use complicated window
> > structures in a frame.
> 
> This suggestion is IMHO less desirable than a feature that allows you to 
> run arbitrary Lisp code and restore the window configuration after that 
> code finishes.

For the sort of command that Joachim was talking about, saving a
window-configuration (via current-window-configuration or something,
since as I explained above, save-window-excursion can't be used in this
situation) and restoring it later simply doesn't work well, at least
without some more cleverness -- and what the necessary cleverness is,
I don't know.

The basic problem is that it's quite common for people to rearrange
their windows before e.g. finishing their checkin, and if the latter
action suddenly restores everything to an old state, people get upset.

That's why such commands usually just pop up a buffer and then delete
it -- the resulting state may not be what the user actually wants, but
at least it results only in `local' changes, which are much less
surprising that the whole window tree suddenly rearranging itself.

Of course, some people may _want_ the former behavior, but you
can't read the user's mind and see which one is right, and the latter
method is at least somewhat more benign.

> One problem with splitting the current window is that it's unreliable:
> if the current window is too small, it might be impossible to split
> it.

Sure, but as a heuristic for a particular case, it may be usable.

-Miles
-- 
"1971 pickup truck; will trade for guns"