* bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0)
@ 2009-11-20 20:01 jidanni
2009-11-20 23:09 ` Jan Djärv
0 siblings, 1 reply; 2+ messages in thread
From: jidanni @ 2009-11-20 20:01 UTC (permalink / raw
To: emacs-pretest-bug; +Cc: rfrancoise
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.
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.
(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.)
In GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.18.3)
of 2009-11-15 on elegiac, modified by Debian
(emacs-snapshot package, version 1:20091115-1)
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0)
2009-11-20 20:01 bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0) jidanni
@ 2009-11-20 23:09 ` Jan Djärv
0 siblings, 0 replies; 2+ messages in thread
From: Jan Djärv @ 2009-11-20 23:09 UTC (permalink / raw
To: jidanni, 4995; +Cc: emacs-pretest-bug, rfrancoise
jidanni@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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-11-20 23:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-20 20:01 bug#4995: 23.1.50; No size compensation for (tool-bar-mode 0)(menu-bar-mode 0) jidanni
2009-11-20 23:09 ` Jan Djärv
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.