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 -*- ericding_at_San-Jose.ate.slb.com
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed Sep 20 1995 - 19:44:33 BST