Re: Weird frame/buffer interaction

Re: Weird frame/buffer interaction

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> "Michael P. Broida" wrote:
> > 
> >         I can grab the modebar [[right term?]] for a window and drag it
> >         downwards to compress the window or windows below it.
> > 
> >         But here's what's weird::  SOMETIMES, it will compress several
> >         windows below the bar, but sometimes it will NOT compress more
> >         than one window.  It even varies within one editting session:
> >         in my current session (6 windows), it has changed "allowance"
> >         four times since I started writing this note (non-Emacs mail
> >         lient) and I can't figure out WHY.  The "rule" seems to change
> >         every 2-3 seconds!
> 
> Please describe the precise details of the window configuration: what are
> the exact dimensions, in character rows and columns, of your Emacs frame,
> how many lines are in each window, and what is the order of the windows, top
> to bottom.
> 
> In general, Emacs tries to make each window no smaller than a certain amount
> of line, but the effect of dragging should only depend on the current sizes
> of all the windows on the frame.  If it sounds like it depends on something
> else, please tell the details as mentioned above.

With latest CVS head (under X):

I just tried to create 6 windows on a frame (50x132) with 
the sequence:
 C-x 2 C-x 2 C-x 2
 (click mouse in bottom window)
 C-x 2
 (make second window from the top larger by dragging its mode-line downwards)
 C-x 2

I then grabbed the mode-line of the topmost window with the mouse and
dragged downwards.  This makes all the windows smaller - until a
certain point where suddenly all windows are evenly sized over the
entire frame.  

Very surprising (as I recall it, windows used to disappear when they
got too small, but I may be mistaken).

Depending on the sequence in which the windows are split, the "magic"
resizing of the windows seem to affect all or only some of the
windows.  So it is might be related to "parent/child" window
relationships?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Weird frame/buffer interaction

[Richard Stallman]

    I just tried to create 6 windows on a frame (50x132) with 

I can't even see the bottom window when I try this, not even with font 5x7.
So I can't debug it.  But I can answer some questions:

    Depending on the sequence in which the windows are split, the "magic"
    resizing of the windows seem to affect all or only some of the
    windows.  So it is might be related to "parent/child" window
    relationships?

Not in a case like this.  When all the splittings are vertical,
you get one set of equal siblings under a single parent window.

Can you make the problem happen using C-x ^?  That way you could
determine more precisely when the problem happens, so you could get
set up such that the next C-x ^ command will produce the problem.
That would make it more convenient to step thru and see why it
suddenly makes all the windows equal in size.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

Hi!
	I was CC'd on the below message, and figured I'd
	throw my two cents in to cloud the issue.  <grin>

	I don't know what "magic resize" you're talking
	about.  My original post was about the fact that
	SOMETIMES I can drag a modebar down and it will
	compress several windows below it, but OTHER TIMES
	it will only compress the FIRST window below the
	bar then will STOP moving.  I can't see any kind
	of pattern on when it allow or disallows that
	resizing to occur.

	Hope that helps a bit.

		Thanks for looking at it, folks!
			Mike

> ----------
> From: 	Richard Stallman[SMTP:rms@gnu.org]
> Reply To: 	rms@gnu.org
> Sent: 	Sunday, March 03, 2002 10:07 PM
> To: 	storm@cua.dk
> Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org; michael.p.broida@boeing.com
> Subject: 	Re: Weird frame/buffer interaction
> 
>     I just tried to create 6 windows on a frame (50x132) with 
> 
> I can't even see the bottom window when I try this, not even with font
> 5x7.
> So I can't debug it.  But I can answer some questions:
> 
>     Depending on the sequence in which the windows are split, the "magic"
>     resizing of the windows seem to affect all or only some of the
>     windows.  So it is might be related to "parent/child" window
>     relationships?
> 
> Not in a case like this.  When all the splittings are vertical,
> you get one set of equal siblings under a single parent window.
> 
> Can you make the problem happen using C-x ^?  That way you could
> determine more precisely when the problem happens, so you could get
> set up such that the next C-x ^ command will produce the problem.
> That would make it more convenient to step thru and see why it
> suddenly makes all the windows equal in size.
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

Hi again!
	OK, I just now saw what I assume is the "magic resize" you
	mentioned.  VERY disconcerting.

	I had 6 windows in one frame, and was able to shrink the
	bottom 4 of them down to their minimum size normally.
	(NOTE: that minimum size seems to SOMETIMES be "1",
	SOMETIMES "2", and SOMETIMES "3".  VERY weird.)

	When I tried to expand the very top window such that all
	the others would be minimum size at the bottom, it stopped
	when it reached that "all minimum" state.  But my mouse hand
	continued to move downward and suddenly all the lower
	windows "magically resized" to 5 or 6 lines tall.  This is
	unpleasant, to say the least.

	I was able to, carefully, shrink each one back to minimum
	again.  And I was able to reproduce that magic resizing
	several times in a row.

Stats:
	GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381) of 2001-10-22 on buffy
	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.

NOTE: I still often get that condition where dragging the modebars
	down SOMETIMES allow and SOMETIMES disallows the compression
	of multiple windows below that modebar.  Perhaps it is related
	in some way.  Holler for details.

		Mike

> ----------
> From: 	Richard Stallman[SMTP:rms@gnu.org]
> Reply To: 	rms@gnu.org
> Sent: 	Sunday, March 03, 2002 10:07 PM
> To: 	storm@cua.dk
> Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org; michael.p.broida@boeing.com
> Subject: 	Re: Weird frame/buffer interaction
> 
>     I just tried to create 6 windows on a frame (50x132) with 
> 
> I can't even see the bottom window when I try this, not even with font
> 5x7.
> So I can't debug it.  But I can answer some questions:
> 
>     Depending on the sequence in which the windows are split, the "magic"
>     resizing of the windows seem to affect all or only some of the
>     windows.  So it is might be related to "parent/child" window
>     relationships?
> 
> Not in a case like this.  When all the splittings are vertical,
> you get one set of equal siblings under a single parent window.
> 
> Can you make the problem happen using C-x ^?  That way you could
> determine more precisely when the problem happens, so you could get
> set up such that the next C-x ^ command will produce the problem.
> That would make it more convenient to step thru and see why it
> suddenly makes all the windows equal in size.
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

More:	When it does that resize, it does NOT make them all
	the same size.  It makes all EXCEPT the top window
	be the same size.  AND it appears that the distance
	my mouse pointer strays below the modebar before the
	resize happens affects the new sizes of those windows.

	I did the dragging and went WELL below the stopped
	modebar and the windows resized to 8-10 lines each.

	I re-did the dragging and went just a TINY bit below
	the mode bar and the windows resized to 1 line each!
	And that "1 line" is, I believe, less than the minimum
	size (that I haven't changed from default).

	Well, I'm hoping these data points might help you.

		Mike


> ----------
> From: 	EXT-Broida, Michael P
> Sent: 	Tuesday, March 05, 2002 11:02 AM
> To: 	storm@cua.dk; 'rms@gnu.org'
> Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org
> Subject: 	RE: Weird frame/buffer interaction
> 
> Hi again!
> 	OK, I just now saw what I assume is the "magic resize" you
> 	mentioned.  VERY disconcerting.
> 
> 	I had 6 windows in one frame, and was able to shrink the
> 	bottom 4 of them down to their minimum size normally.
> 	(NOTE: that minimum size seems to SOMETIMES be "1",
> 	SOMETIMES "2", and SOMETIMES "3".  VERY weird.)
> 
> 	When I tried to expand the very top window such that all
> 	the others would be minimum size at the bottom, it stopped
> 	when it reached that "all minimum" state.  But my mouse hand
> 	continued to move downward and suddenly all the lower
> 	windows "magically resized" to 5 or 6 lines tall.  This is
> 	unpleasant, to say the least.
> 
> 	I was able to, carefully, shrink each one back to minimum
> 	again.  And I was able to reproduce that magic resizing
> 	several times in a row.
> 
> Stats:
> 	GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381) of 2001-10-22 on buffy
> 	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.
> 
> NOTE: I still often get that condition where dragging the modebars
> 	down SOMETIMES allow and SOMETIMES disallows the compression
> 	of multiple windows below that modebar.  Perhaps it is related
> 	in some way.  Holler for details.
> 
> 		Mike
> 
> 	----------
> 	From: 	Richard Stallman[SMTP:rms@gnu.org]
> 	Reply To: 	rms@gnu.org
> 	Sent: 	Sunday, March 03, 2002 10:07 PM
> 	To: 	storm@cua.dk
> 	Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org;
> michael.p.broida@boeing.com
> 	Subject: 	Re: Weird frame/buffer interaction
> 
> 	    I just tried to create 6 windows on a frame (50x132) with 
> 
> 	I can't even see the bottom window when I try this, not even with
> font 5x7.
> 	So I can't debug it.  But I can answer some questions:
> 
> 	    Depending on the sequence in which the windows are split, the
> "magic"
> 	    resizing of the windows seem to affect all or only some of the
> 	    windows.  So it is might be related to "parent/child" window
> 	    relationships?
> 
> 	Not in a case like this.  When all the splittings are vertical,
> 	you get one set of equal siblings under a single parent window.
> 
> 	Can you make the problem happen using C-x ^?  That way you could
> 	determine more precisely when the problem happens, so you could get
> 	set up such that the next C-x ^ command will produce the problem.
> 	That would make it more convenient to step thru and see why it
> 	suddenly makes all the windows equal in size.
> 
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

Sorry to keep sending messages, but I'm finding more details
that might help.

That magic resizing is really odd.  If I continue to hold
down the mouse button, the windows (EXCEPT the top one)
keep changing sizes: springing up and down pretty wildly
with just tiny mouse movements.

Also note that it SEEMS to only happen if I'm dragging the
UPPERMOST modebar (below the top window), NOT any lower bar.
Dragging the 2nd/3rd/etc modebar does NOT cause any unexpected
resizing (though it still sometimes lets me squish multiple
lower windows and sometimes does not allow that).

	Mike


> ----------
> From: 	EXT-Broida, Michael P
> Sent: 	Tuesday, March 05, 2002 11:07 AM
> To: 	'storm@cua.dk'; 'rms@gnu.org'
> Cc: 	'eliz@is.elta.co.il'; 'emacs-devel@gnu.org'
> Subject: 	RE: Weird frame/buffer interaction
> 
> More:	When it does that resize, it does NOT make them all
> 	the same size.  It makes all EXCEPT the top window
> 	be the same size.  AND it appears that the distance
> 	my mouse pointer strays below the modebar before the
> 	resize happens affects the new sizes of those windows.
> 
> 	I did the dragging and went WELL below the stopped
> 	modebar and the windows resized to 8-10 lines each.
> 
> 	I re-did the dragging and went just a TINY bit below
> 	the mode bar and the windows resized to 1 line each!
> 	And that "1 line" is, I believe, less than the minimum
> 	size (that I haven't changed from default).
> 
> 	Well, I'm hoping these data points might help you.
> 
> 		Mike
> 
> 
> 	----------
> 	From: 	EXT-Broida, Michael P
> 	Sent: 	Tuesday, March 05, 2002 11:02 AM
> 	To: 	storm@cua.dk; 'rms@gnu.org'
> 	Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org
> 	Subject: 	RE: Weird frame/buffer interaction
> 
> 	Hi again!
> 		OK, I just now saw what I assume is the "magic resize" you
> 		mentioned.  VERY disconcerting.
> 
> 		I had 6 windows in one frame, and was able to shrink the
> 		bottom 4 of them down to their minimum size normally.
> 		(NOTE: that minimum size seems to SOMETIMES be "1",
> 		SOMETIMES "2", and SOMETIMES "3".  VERY weird.)
> 
> 		When I tried to expand the very top window such that all
> 		the others would be minimum size at the bottom, it stopped
> 		when it reached that "all minimum" state.  But my mouse hand
> 		continued to move downward and suddenly all the lower
> 		windows "magically resized" to 5 or 6 lines tall.  This is
> 		unpleasant, to say the least.
> 
> 		I was able to, carefully, shrink each one back to minimum
> 		again.  And I was able to reproduce that magic resizing
> 		several times in a row.
> 
> 	Stats:
> 		GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381) of 2001-10-22 on
> buffy
> 		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.
> 
> 	NOTE: I still often get that condition where dragging the modebars
> 		down SOMETIMES allow and SOMETIMES disallows the compression
> 		of multiple windows below that modebar.  Perhaps it is
> related
> 		in some way.  Holler for details.
> 
> 			Mike
> 
> 		----------
> 		From: 	Richard Stallman[SMTP:rms@gnu.org]
> 		Reply To: 	rms@gnu.org
> 		Sent: 	Sunday, March 03, 2002 10:07 PM
> 		To: 	storm@cua.dk
> 		Cc: 	eliz@is.elta.co.il; emacs-devel@gnu.org;
> michael.p.broida@boeing.com
> 		Subject: 	Re: Weird frame/buffer interaction
> 
> 		    I just tried to create 6 windows on a frame (50x132)
> with 
> 
> 		I can't even see the bottom window when I try this, not even
> with font 5x7.
> 		So I can't debug it.  But I can answer some questions:
> 
> 		    Depending on the sequence in which the windows are
> split, the "magic"
> 		    resizing of the windows seem to affect all or only some
> of the
> 		    windows.  So it is might be related to "parent/child"
> window
> 		    relationships?
> 
> 		Not in a case like this.  When all the splittings are
> vertical,
> 		you get one set of equal siblings under a single parent
> window.
> 
> 		Can you make the problem happen using C-x ^?  That way you
> could
> 		determine more precisely when the problem happens, so you
> could get
> 		set up such that the next C-x ^ command will produce the
> problem.
> 		That would make it more convenient to step thru and see why
> it
> 		suddenly makes all the windows equal in size.
> 
> 
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Weird frame/buffer interaction

[Richard Stallman]

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.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Weird frame/buffer interaction

[Richard Stallman]

	    (NOTE: that minimum size seems to SOMETIMES be "1",
	    SOMETIMES "2", and SOMETIMES "3".  VERY weird.)

Do these different minimum sizes occur randomly, or do they correlate
reproducibly with circumstances?  If the latter, can you send a
*precise test case* for how to find a minimum of 3?


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

Seems to be random to me.  I can shrink the windows
below a modebar and it might stop with them all at
3 lines each.  Then I expand all the windows by hand
(drag each modebar upwards) and shrink them again
and it might stop at 1 or 2 lines each.

> ----------
> From: 	Richard Stallman[SMTP:rms@gnu.org]
> Reply To: 	rms@gnu.org
> Sent: 	Wednesday, March 06, 2002 8:30 PM
> To: 	michael.p.broida@boeing.com
> Cc: 	storm@cua.dk; eliz@is.elta.co.il; emacs-devel@gnu.org
> Subject: 	Re: Weird frame/buffer interaction
> 
> 	    (NOTE: that minimum size seems to SOMETIMES be "1",
> 	    SOMETIMES "2", and SOMETIMES "3".  VERY weird.)
> 
> Do these different minimum sizes occur randomly, or do they correlate
> reproducibly with circumstances?  If the latter, can you send a
> *precise test case* for how to find a minimum of 3?
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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:rms@gnu.org]
> Reply To: 	rms@gnu.org
> Sent: 	Wednesday, March 06, 2002 8:30 PM
> To: 	michael.p.broida@boeing.com
> Cc: 	storm@cua.dk; eliz@is.elta.co.il; emacs-devel@gnu.org
> 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.
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

RE: Weird frame/buffer interaction

[EXT-Broida, Michael P]

OK, here's info suggested/requested by the Emacs "BUGS" manual section.

This is all about that "Magic Resizing" that happens when dragging a
modebar down "beyond" the minimum size for all windows below that bar.

Following chunks of info are:
1) "M-x report-emacs-bug" output
	(Please read the embedded small note with "RecentInput"
	 additions that will help see EXACTLY what I did from
	 starting Emacs until beginning the "report-emacs-bug".)
2) System info
3) Emacs mods made.
4) Contents of .emacs and site-start.el files
5) How to reproduce the problem.
6) Termscript info

	Let me know if you need more info.  I'll try to stop
	guessing about the causes; I don't know the Emacs internals
	enough to make good guesses.  <grin>

*1********************************************
To: bug-gnu-emacs@gnu.org
Subject: Magic Resizing
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-msvc-nt4.0.1381)
 of 2001-10-22 on buffy
configured using `configure --with-msvc (12.00)'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Test case matches "20 line frame" I sent you previously:
one 20-line frame, three 6 line windows (+1 line minibuffer)
on separate buffers each with 10 lines of numbers.  Drag
top modebar downwards to the point where all LOWER windows
reach minimum size, drag a bit further down and all the
lower windows "magically" resize.  The motion in this small
test window is "vigorous/violent" and CONTINUOUS until the
mouse is released or moved upwards.
See the "BROIDA NOTE" immediately following the Recent Input
block!! That shows ALL input from start of Emacs.

Recent input:
C-x ^ C-x ^ C-x o C-x b t e m p 3 <return> C-y <escape> 
< <help-echo> <down-mouse-1> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <mouse-movement> <help-echo> 
<mouse-movement> <help-echo> <mouse-movement> <help-echo> 
<mouse-movement> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<help-echo> <mouse-movement> <help-echo> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <drag-mouse-1> M-x 
r e p o r t - e m a c s - b u g <return>

[[BROIDA NOTE:
The above is the best I could get in a BugReport capture; in
most cases, the "mouse-movement" entries were so numerous that
no keystrokes remained in the list.  I did the capture once
BEFORE I started the mouse dragging in order to get ALL the
inputs up to that point.  (The above was from a repeat of the
full testing.)  If you add the following block right BEFORE
the above Recent Input block, you'll have EVERYTHING that I
did from the time I opened Emacs.
******StartBlock******
C-x b t e m p 1 <return> 1 <return> 2 <return> 3 <return> 
4 <return> 5 <return> 6 <return> 7 <return> 8 <return> 
9 <return> 1 0 <return> C-@ <escape> < <escape> w C-x 
2 C-x 2 C-x ^ C-x ^ C-x o C-x b t e m p 2 <return> 
C-y <escape> < C-x ^ 
******EndBlock******
END BROIDA NOTE:]]


Recent messages:
(C:\emacs-21.1\bin\emacs.exe)
For information about the GNU Project and its goals, type C-h C-p.
Loading image...done
Mark set [6 times]
Loading emacsbug...done


*2********************************************
	WinNT 4.0 with SP6 (I'm pretty sure about the SP#,
	but can't find that info without rebooting.).

*3********************************************
	Emacs pre-compiled binaries with pre-compiled Lisp stuff.
		Installed "normally": extract files and run addpm.exe.
		NO mods made other than adding diff.exe and diff3.exe
		 program files to bin directory and setting up the
		 site-start.el file (below).
	Installed in "C:\emacs-21.1" directory.

*4********************************************
	NO .emacs file present anywhere on the system.
	Contents of site-start.el file: (one line)
(setq initial-frame-alist '((top . 1) (left . 1) (width . 70) (height .
22)))
	Use that to get the frame size for the test case.
	No other init files that I know of; if any exist,
	they came with the default download/install.
	(No other users of this system at all.)

*5********************************************
	To reproduce the problem, just do everything in
	the RecentInput list (including the added BROIDA
	NOTE at the end of that list).  All of the "mouse-
	movement" events are from grabbing the right half
	of the topmost modebar and dragging it downwards
	until it goes nuts.  <grin>
	Started Emacs by clicking on the desktop icon.

*6********************************************
	Termscript info: "M-: (open-termscript "~/termscript")
	results in "nil" in the minibuffer.  This is just
	a vanilla DELL monitor on a dual-Pentium3 system.

Please holler if you need more info!
		Mike


> ----------
> From: 	Richard Stallman[SMTP:rms@gnu.org]
> Reply To: 	rms@gnu.org
> Sent: 	Wednesday, March 06, 2002 8:30 PM
> To: 	michael.p.broida@boeing.com
> Cc: 	storm@cua.dk; eliz@is.elta.co.il; emacs-devel@gnu.org
> 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.
> 

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel