martin rudalics writes: >> I've attached a diff with my edits; if/when some version of this is >> eventually approved I can do a proper commit. > > Thanks. Please install. > >> I didn't add anything in the Window Parameters section about the first >> two elements of the quit-restore parameter, simply because I don't >> understand them well enough. I still think something should be said >> there about how they influence quit behavior, though -- this is the >> first place that people will look to find out how this works, and the >> current docs are very clear about "what", but beg the question of "why". Okay, I got distracted for a while there, but here's another version. I reworked the `quit-restore-window' section, and now it makes sense to me, at any rate. I'm fairly uncertain about this paragraph: The window is deleted entirely if: 1) the first element of the @code{quit-restore} parameter is one of 'window or 'frame, 2) the window has no history of previously-displayed buffers, and 3) the displayed buffer matches the one in the fourth element of the @code{quit-restore} parameter. The window will never be deleted, however, if it is the only one in its frame. If @var{window} is the only window on its frame and there are other frames on the frame's terminal, the value of the optional argument @var{bury-or-kill} determines how to proceed with the window. If @var{bury-or-kill} equals @code{kill}, the frame is deleted unconditionally. Otherwise, the fate of the frame is determined by calling @code{frame-auto-hide-function} (see below) with that frame as sole argument. I just don't see how/where the `bury-or-kill' parameter affects the handling of the frame, I think it only affects the buffer. But I may have "fixed" it until it doesn't make sense :) I added a line about 'same as the first element of `quit-restore', but it might be wrong. I didn't add anything new about the 'other symbol. I see it getting set in `display-buffer-record-window', but I don't see that it ever gets used. Hope this is nearly there, Eric