RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

Hmm,
I've always found that determining the limits of the symptoms of a problem
will VERY OFTEN narrow the problem area down significantly.  It helps point
out what is NOT part of the problem.  In the case of Emacs, I know diddly
about the internals, so I'm probably just thrashing around.  <grin>

Lots of info in this post; I hope it's all useful:
        (I just read the Manual "BUGS" part as you suggested
        and will send recommended items in a followup e-mail.)

Try this for a test setup:  (Second even smaller frame test below.)
A frame of 27 lines PLUS the modebar and a 1-line minibuffer at the bottom.
Setup 4 windows each 6 lines + modebar: use C-x 2 to split the main window,
then C-x 2 in each of those halves to make a total of four equal windows.
Make each window show a different buffer; I put ten lines of numbers in each
buffer.  Mode of the buffer doesn't seem to matter: "Fundamental" does the
same thing as "C++", though I haven't tried combinations.

Now grab the TOP modebar (below the top window) somewhere on the right half
and slowly drag it down.  *IF* it allows you to shrink ALL lower windows
(see NOTE2 below), you will eventually reach a point where all the lower
windows are "minimum size" as set in the Customization Group "Environment"->
"Windows" in "Window Min Height".  Mine is set to "4" (default), but it
allows the modebar dragging to shrink EACH window to 3 lines PLUS modebar.

DON'T RELEASE THE MOUSE BUTTON.
Once it has reached that point (all lower windows at minimum), if you keep
dragging even a TINY bit lower, it suddenly resizes those lower windows all
at the same time and continued dragging up/down will cause them to continue
to resize rapidly.  I'm seeing that it often resizes them all back to 4
lines
PLUS modebar, but if I move the mouse more "suddenly", it will sometimes
make
them each 5 or 6 lines + modebar.  It is NOT consistent, but the general
effect is completely reproducible here.  The minibuffer at the bottom is not
resized by any of this activity.

It does NOT seem to happen if I grab the SECOND modebar from the top (below
the second window) and drag down.  Also doesn't happen on the THIRD modebar,
but there's only one window below that one.

Second test setup:
I just setup a smaller test: frame of 20 lines + modebar + oneline
minibuffer.
THREE windows of 6 lines + modebar each.  Drag top modebar down and same
thing happens, but this time the resizing is more drastic: varies between
1, 2, and 3 lines per lower window AND it shifts VERY RAPIDLY/VIOLENTLY
and CONSTANTLY SHIFTING with just a tiny mouse movement after reaching the
initial "all lower windows at minimum size" point.  This behavior seems to
be reproducible: meaning it did it every time I tried the dragging part.

Well, I hope that test description leads you to something good.  :)

NOTE1:
I just noticed that the Customization Group "Windows" element "Even Window
Heights" is (non-nil) here [I never changed default] and that says that
"'display-buffer' should even the window heights".  Is that interacting
with the modebar dragging to cause this "magic resizing??  Well, NOPE: I
turned that to (nil) and set it for this session and it still does the
resizing.  Or maybe that setting is ignored??  More probably: I don't
understand the meaning of that description.  <grin>

NOTE2: Aside from the "magic resizing", there is the (possibly separate)
issue (that HAS occurred during the above testing) where Emacs will
sometimes
allow and sometimes NOT allow the modebar dragging to shrink more than the
ONE window immediately below it.  This allow/disallow changes from moment
to moment and I can't see any pattern.  I mention it because it MIGHT be
related (or not).

Please keep me "in the loop", particularly if you need more input.

Details again:
        "GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381) of 2001-10-22 on buffy"
                (unmodified by me; I downloaded pre-compiled binaries)
        WinNT 4.0 with SP6 (I'm pretty sure about the SP#).
        All buffers had either .cpp or .h files in them, thus were in
                "C Abbrev" or "C++ Abbrev" mode.
        Holler if you would like my .emacs and site-start.el files.
                I do just about zero fancy stuff in those files or in
                my use of Emacs.

                Mike


> ----------
> From:         Richard Stallman[SMTP:address@hidden
> Reply To:     address@hidden
> Sent:         Wednesday, March 06, 2002 8:30 PM
> To:   address@hidden
> Cc:   address@hidden; address@hidden; address@hidden
> Subject:      Re: Weird frame/buffer interaction
> 
> I appreciate the effort that you are making to explore the envelope of
> this bug, but that is not an effective way to get to the bottom of
> things.  Information about the envelope of the bug will never lead us
> to the cause of the problem.  That is not the way problems are found.
> 
> What would in fact help is a test case that we can really try.  I
> cannot try the test case that was sent because I can't do anything
> with such a tall frame.  Can you find a test case which uses
> an ordinary size frame?
> 
> I suggest you read the Bugs section in the Emacs manual, which
> explains what information will actually help find the bug.
>