bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Djärv
Subject: bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0)
Date: Sat, 21 Nov 2009 00:09:01 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4



address@hidden 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]