Path: utzoo!utgpu!watmath!uunet!tut.cis.ohio-state.edu!HARVARD.HARVARD.EDU!garyo%playroom
From: garyo%playroom@HARVARD.HARVARD.EDU (Gary Oberbrunner, ...{uunet,harvard}!masscomp!garyo)
Newsgroups: gnu.emacs.bug
Subject: GNU Emacs 18.52 "bug"
Message-ID: <8812052005.AA07568@prep.ai.mit.edu>
Date: 5 Dec 88 20:06:10 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 40


WARNING:  Although this drives me up a wall, it's not truly a bug.

When deleting windows with delete-window, it is not always desirable
to spread the old window's space around among the remaining windows
and select the next window.

Often I'd rather just select the window ABOVE, and absorb the space
from the deleted window into that one.  This more closely parallels
what split-window does, and prevents delete-window from having
unwanted global effects on other windows.

I see this a lot with compilation windows; I compile something (using
a very small 5- or 6-line window on a 60-line screen), then close some
other window elsewhere on the screen and my compilation window changes
size!  Then I have to readjust ALL the windows on the screen (a
non-trivial task for windows in the middle, but that's another story)
to get them back to their state before deleting the window.

I consider a window configuration a vital part of the user interface;
the program (emacs) should not fool with it unless it has to.
Locality concerns would seem to require that the smallest number of
windows be changed arbitrarily on a user event (such as split or
delete).  Do you agree?

I can't see any way to fix this from elisp, since there's no way to
fool with the raw window data structures.  I expect it can be done
from within window.c, but I don't understand it well enough to fix it.
I may get to that point eventually, and if I do I'll send in my code;
if you have any hints I'd love to hear them.

					As always,

					Gary Oberbrunner

----------------------------------------------------------------------------
Remember,			Truth is not beauty;      (508)692-6200x2445
Information is not knowledge;	Beauty is not love;	  Gary   Oberbrunner
Knowledge is not wisdom;	Love is not music;	  ...!masscomp!garyo
Wisdom is not truth;		Music is the best. - FZ   ....garyo@masscomp