Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!cps3xx!rang
From: rang@cpsin3.cps.msu.edu (Anton Rang)
Newsgroups: gnu.emacs.bug
Subject: Re: bug
Message-ID: <1807@cps3xx.UUCP>
Date: 13 Feb 89 18:14:19 GMT
References: <8902121627.AA05481@csseq.tamu.edu>
Sender: usenet@cps3xx.UUCP
Reply-To: rang@cpswh.cps.msu.edu (Anton Rang)
Distribution: gnu
Organization: Michigan State University, Computer Science Dept.
Lines: 26
In-reply-to: romero@CSSEQ.TAMU.EDU's message of 12 Feb 89 16:27:15 GMT

Ron Romero (romero@csseq.tamu.edu) writes:
>  When I call up the calendar function in horizontal split mode, The 
>mini-buffer expands to about half the screen. 

  This is caused by the calendar package shrinking the window.  There
is some code which looks like:

    (or (one-window-p t)
        (<= h l)
        (shrink-window (- h l))))

buried inside cal.el.  I'm not sure of the exact logic, but I think
its intended use is to handle the case where there are two "normal"
windows--the calendar goes in one, which is then shrunk down to size.
  The shrink-window call seems to make the window smaller, even if
only the minibuffer is left to expand--this is why the strange results
occur (try eval-ing (shrink-window 10) in one-window mode to see this).
  I suppose the best fix would be a test to see whether the windows
were split horizontally or vertically, but this would get complicated
with more than one window.  Maybe the semantics of shrink-window
should be changed so that the minibuffer doesn't expand?  Comments?

+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | Things could be worse. | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu |                      |
+---------------------------+------------------------+----------------------+