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: Tue, 5 Mar 2002 11:07:49 -0600 Message-ID: <37D24D4FFB26F74D8F4C82CF039354F1013883C1@xch-stl-08.mw.nos.boeing.com> NNTP-Posting-Host: quimby2.netfonds.no Mime-Version: 1.0 Content-Type: text/plain X-Trace: quimby2.netfonds.no 1015348569 32666 195.204.10.66 (5 Mar 2002 17:16:09 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 5 Mar 2002 17:16:09 GMT Cc: "'eliz@is.elta.co.il'" , "'emacs-devel@gnu.org'" Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16iIXo-0008Um-00 for ; Tue, 05 Mar 2002 18:16:08 +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 16iIR7-00035G-00; Tue, 05 Mar 2002 12:09:13 -0500 Original-Received: from stl-smtpout-01.boeing.com ([12.13.247.21]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16iIQ5-000307-00; Tue, 05 Mar 2002 12:08:09 -0500 Original-Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA22558; Tue, 5 Mar 2002 11:08:00 -0600 (CST) Original-Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA20934; Tue, 5 Mar 2002 11:07:59 -0600 (CST) 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 g25H7xQ28930; Tue, 5 Mar 2002 11:07:59 -0600 (CST) Original-Received: by xch-mwbh-01.mw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <16T49TVH>; Tue, 5 Mar 2002 11:07:58 -0600 Original-To: "'storm@cua.dk'" , "'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:1744 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1744 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