all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "EXT-Broida, Michael P" <michael.p.broida@boeing.com>
Cc: eliz@is.elta.co.il, emacs-devel@gnu.org
Subject: RE: Weird frame/buffer interaction
Date: Tue, 5 Mar 2002 11:02:28 -0600	[thread overview]
Message-ID: <37D24D4FFB26F74D8F4C82CF039354F1013883C0@xch-stl-08.mw.nos.boeing.com> (raw)

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


             reply	other threads:[~2002-03-05 17:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-05 17:02 EXT-Broida, Michael P [this message]
2002-03-07  2:30 ` Weird frame/buffer interaction Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2002-03-07 19:32 EXT-Broida, Michael P
2002-03-07 18:31 EXT-Broida, Michael P
2002-03-07 17:28 EXT-Broida, Michael P
2002-03-05 17:19 EXT-Broida, Michael P
2002-03-07  2:30 ` Richard Stallman
2002-03-05 17:07 EXT-Broida, Michael P
2002-03-04 18:31 EXT-Broida, Michael P
     [not found] <3C7EB0A2.D73F6CD4@boeing.com>
     [not found] ` <3C7F1FA6.2105F03E@is.elta.co.il>
2002-03-01 15:50   ` Kim F. Storm
2002-03-04  4:07     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37D24D4FFB26F74D8F4C82CF039354F1013883C0@xch-stl-08.mw.nos.boeing.com \
    --to=michael.p.broida@boeing.com \
    --cc=eliz@is.elta.co.il \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.