bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0)

[email protected] 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.