GNU bug report logs -
#4995
23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0)
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Fri, 20 Nov 2009 21:15:04 UTC
Severity: normal
Merged with 3643
Done: Jan Djärv <jan.h.d <at> swipnet.se>
Bug is archived. No further changes may be made.
Full log
Message #10 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
jidanni <at> jidanni.org skrev 2009-11-20 21.01:
> ADMIT that
> $ emacs -Q -eval '(progn(tool-bar-mode 0)(menu-bar-mode 0))'
> 1. Still momentarily wastefully shows at least the menu-bar before cleaning it
> off the screen, even if the user does those commands in his .emacs file.
That is because the first frame is visible before .emacs is read, an issue
discussed before.
> 2. But more importantly, gives the user a window shorter than he wants.
> No compensation is made here under X windows to lengthen back the emacs
> window back to the size it was before removing those items.
There are three ways of doing this:
1 Keep number of editable lines
2 Keep height in pixels.
3 Read .emacs before the first frame.
IMHO, the last is the correct solution, but it isn't such a high priority.
After all this is kostly a cosmetic bug, even if annoying.
1 or 2 is equally correct in my eye, if 3 isn't present.
> (Note I had no xrdb emacs items set.) To workaround I must do:
> (setq default-frame-alist (cons (cons 'height (+(frame-height)4)) default-frame-alist))
> (No, fullhight, fullboth,(which by the way is not documented) don't let
> one still see the ICEWM toolbar.)
Currently Emacs just tells the WM to do the resizing, so if some WM-specific
toolbar isn't shown, Emacs is not to blame.
You are just not looking hard enough for documentation:
% emacs -Q
C-h i
m elisp<return>
s fullscreen<return>
Jan D.
This bug report was last modified 15 years and 95 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.