🚀 go-pugleaf

In article <9004121352.AA18442@gem>, pastor@PRC writes:

... a bunch of gripes that Kyle Jones already dealt with, plus this
one where Kyle threw up his hands (and his smiley (-:):

>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.

... but if you are deleting a window then it is *not* the way you
wanted it, now is it?  So emacs has to put the extra space
*somewhere*.

>						     I want the space
>given up to the window above the one that is being deleted, as it is in
>Unipress Emacs.

Aha!  you just want it to be "the way it is in editor 'foo'", albeit
one that also calls itself emacs.  The writer of gosmacs.el didn't
feel this one was worthy of including, but maybe someone else out
there has done this.  At any rate, based on code in saveconf.el (also
courtesy Kyle Jones) you ought to be able to code this in elisp.
Bascially, you record the current windows in a list (saveconf has a
function that does this), the record their sizes, then delete the
current window, then go through all the other windows forcing their
sizes to be what you want with, e.g., enlarge-window.  To avoid
squashing some window off the screen, it ought to do the shrinks
followed by the grows.

>		  This behavior facilitates splitting a window to look
>around in a file that you're already editing, then getting  rid of the
>window when you're done, a technique I used to use all the time until I
>switched over to GNU Emacs.  Now it's such a pain to do it that I'm
>forced to jump around in the file within the same window.

Reasonable enough request.  If you aren't up to the elisp coding,
maybe someone else will be.
--
/jr, nee John Robinson     Life did not take over the globe by combat,
jr@bbn.com or bbn!jr          but by networking -- Lynn Margulis