From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: "EXT-Broida, Michael P" Newsgroups: gmane.emacs.devel Subject: RE: Weird frame/buffer interaction Date: Thu, 7 Mar 2002 12:31:57 -0600 Message-ID: <37D24D4FFB26F74D8F4C82CF039354F1036B31C8@xch-stl-08.mw.nos.boeing.com> NNTP-Posting-Host: quimby.gnus.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: quimby.gnus.org 1015567766 28502 80.91.224.244 (8 Mar 2002 06:09:26 GMT) X-Complaints-To: usenet@quimby.gnus.org NNTP-Posting-Date: 8 Mar 2002 06:09:26 GMT Cc: storm@cua.dk, eliz@is.elta.co.il, emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16jDZF-0007PK-00 for ; Fri, 08 Mar 2002 07:09:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16j2hZ-0004Jq-00; Thu, 07 Mar 2002 13:33:17 -0500 Original-Received: from blv-smtpout-01.boeing.com ([192.161.36.5]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16j2gN-0003yY-00; Thu, 07 Mar 2002 13:32:03 -0500 Original-Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA16419; Thu, 7 Mar 2002 10:32:01 -0800 (PST) Original-Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA19278; Thu, 7 Mar 2002 10:32:00 -0800 (PST) Original-Received: from xch-mwbh-01.mw.nos.boeing.com (xch-mwbh-01.mw.nos.boeing.com [130.38.5.20]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g27IVxQ19136; Thu, 7 Mar 2002 12:31:59 -0600 (CST) Original-Received: by xch-mwbh-01.mw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <16TVDMNT>; Thu, 7 Mar 2002 12:31:59 -0600 Original-To: "'rms@gnu.org'" X-Mailer: Internet Mail Service (5.5.2650.21) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:1788 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1788 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. 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. 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