Subject: FVWM: still having prob with emacs 19.25-29 initial resize

From: Eric Ding <[email-masked]>
Date: Wed, 20 Sep 1995 17:48:04 -0700

Hi,

I'm still having probs with emacs 19.25 and .29 (and I assume all in
between) here on a Sparc 5 running SunOS 4.1.3_U1 and fvwm pre-2.0pl35.
Emacs was configured with sparc-sun-sunos4shr --with-x-toolkit=athena
 --with-gcc.

This problem does *not* happen in any other window manager (twm, mwm,
vtwm.gamma), including fvwm 1.24r, so I'm still inclined to think it's an
fvwm pre-2.0 bug, not an emacs bug.  I'm hoping someone can help...

If the first X-related thing done to a frame is to turn off the menu bar,
then the window doesn't resize appropriately; it shrinks down when the menu
bar disappears, but doesn't resize (increase height by 1) when emacs
resizes its buffer to take advantage of the extra room.  This results in a
hidden minibuffer, until I manually resize the window using the window
manager.  I can duplicate this with a test file:

(menu-bar-mode nil)

and then loading it, i.e.,

	emacs -q -l test-menu.el &

The results are even more dramatic -- big white space at the bottom of a
resized window -- if I have the line

(setq default-frame-alist '((width . 80) (height . 49) (menu-bar-lines . 0)))

instead (with no X resources set; the default height is 40).

I believe this is an fvwm bug, though I can't check the emacs because the
frame operations, I think, are primitive.  Help?

Thanks,
Eric
--                                         |
1601 Technology Drive                     -*- [email-masked]
San Jose, CA 95110-1397                    |          PHONE: (408) 437-5068
http://web.mit.edu/ericding/www/home.html  |            FAX: (408) 437-5246
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].