🚀 go-pugleaf

Somebody complained:

>>While I'm at it, nobody has been able to tell me how to cure another
>>behavior that I also regard as a bug if it is not used-controllable. 
>>When I delete a window, I do not want the space thus liberated
>>distributed among all other windows; I have arranged my screen the way
>>I want it, and I don't want Emacs to mess with it.  I want the space
>>given up to the window above the one that is being deleted, as it is in
>>Unipress Emacs.

In article <54871@bbn.COM> jr@bbn.com (John Robinson) writes:

>Aha!  you just want it to be "the way it is in editor 'foo'", albeit
>one that also calls itself emacs.

Fooey on this line of argument.  To choose a way to do something
specifically because some other editor does or does not do it that way
is foolish.  You should choose to do it the way that is most
convenient , sensible , useful, or obvious, to the user.  Other
choices will result in less useable editors.

I agree with the original complaint.  There should be a way to give
all the window space recovered from a deleted window to a particular
remaining window, rather than distributing it evenly among all
remaining windows.

When in gnus, I frequently have a need to split off an additional
window for a bit.  Later I delete this temporary window.  The result
is that the "subject" window slowly grows, at the expense of the
"article" window.  I want the article window to remain as big as is
convenient, and so I must shrink-window the "subject" window.

I suspect this problem will be annoying in any situation where you
have a small window for directing the contents of some larger window
in which you're reading.  Other examples of such small/large pairs are
mail handlers (headers/text) and error corrections after compilation
(errors/source).

>At any rate, based on code in saveconf.el, [screamingly ugly hack deleted] 
--
	Ben Chase <bbc@rice.edu>, Rice University, Houston, Texas