Assume you have a nnn x 1200 resolution and start up your emacs with -fn 6x13. You will realize, that it won't accept higher geometry values than 85 for height and will also assume a max. 85 when called with the -fh option. Which is annoying. Reproducible: Always Steps to Reproduce: 1. Set resolution to something x 1200 or higher 2. emacs -fn 6x13 -geometry 100x87 Actual Results: emacs draws a window as if -geometry 100x85 was called Expected Results: To honor any geometry value I give it. Most probably this will go upstream. There is an easy workaround by simply resizing the window by mouse.
Which Emacs version are you using? And with which can you reproduce?
$ emacs --version GNU Emacs 23.1.1 We first observed this behaviour with 22.x versions (which doesn't mean it wasn't there before). Reproducible with 22.x and 23.x versions so far. -fh has the same effect (max. 85 height), while --fullscreen works as expected. Also, you can reproduce it with lower Y-resolutions than 1200, as long as you set the font small enough (e.g. -fn 5x8).
(In reply to comment #0) > Steps to Reproduce: > 1. Set resolution to something x 1200 or higher > 2. emacs -fn 6x13 -geometry 100x87 > > Actual Results: > emacs draws a window as if -geometry 100x85 was called Of the 87 lines in the frame, one line is used up for the mode line, another for the minibuffer. So 87 - 2 = 85 lines are left for the window. This looks normal to me.
(In reply to comment #3) > > 2. emacs -fn 6x13 -geometry 100x87 > > > > Actual Results: > > emacs draws a window as if -geometry 100x85 was called > > Of the 87 lines in the frame, one line is used up for the mode line, another > for the minibuffer. So 87 - 2 = 85 lines are left for the window. This looks > normal to me. I'm sure if you look once again, this will change. Bad example. Try geometry 100x100, this will yield the same results like 100x85. 85 seems to be a hardcoded limit somewhere. Even if your deduction was correct, 100x85 should STILL yield a different result than 100x87 - just with a Y-offset of -2.
Sorry, but I can't reproduce it here. I get a window with 98 lines for -geometry 100x100 and 83 lines for -geometry 100x85. Does the problem also occur: a) if you start Emacs with the -Q option? b) with a different window manager? c) under another (newly created) account? And please post the output of "emerge -pv emacs".
(In reply to comment #5) > Does the problem also occur: > a) if you start Emacs with the -Q option? Actually no. So I dug into the matter. It turned out, that -q was enough to stop that behaviour. So I removed all .emacs/.gnu-emacs files from my home. The behaviour stopped. As soon as this .emacs file (and nothing else) is in my home, Emacs shows the described behaviour: --------------------- (custom-set-variables ;; ;; Emacs behaviour and main look & feel ;; '(inhibit-startup-screen t) ;; inhibit startup screen '(tool-bar-mode nil) ;; inhibit toolbar icons '(scroll-bar-mode (quote right)) ;; we want our scrollbar on the right side '(size-indication-mode t) ;; show size of file '(column-number-mode t) ;; show number of column cursor is in ;; ;; PERL editing specifics ;; '(cperl-close-paren-offset -4) ;; CPERL: ?? '(cperl-continued-statement-offset 4) ;; CPERL: ?? '(cperl-indent-level 4) ;; CPERL: 4 char indentation '(cperl-indent-parens-as-block t) ;; CPERL: ?? '(cperl-tab-always-indent t) ;; CPERL: ?? ) ;; folding should be done with simple C-c prefix, not C-c @ (setq folding-default-keys-function 'folding-bind-backward-compatible-keys) ;; Insert spaces instead of tabs (setq-default indent-tabs-mode nil) (load "folding" 'nomessage) --------------------- I fail to see the reason. I have app-emacs/folding (2009.0905.0811) app-emacs/cperl-mode (6.2) installed > b) with a different window manager? > c) under another (newly created) account? Have not tried that yet, because that obove seems like the culprit - whatever it is. > And please post the output of "emerge -pv emacs". $ emerge -pv emacs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-editors/emacs-23.1-r2 USE="X Xaw3d alsa dbus gif jpeg png sound svg tiff -gpm -gtk -gzip-el -hesiod -kerberos -m17n-lib -motif -source -toolkit-scroll-bars -xft -xpm" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
OMG... you can safely discard most of what I said in comment#6 and this claim from comment2: >Also, you can reproduce it with lower Y-resolutions than 1200, as long as you >set the font small enough (e.g. -fn 5x8). THe important news is, there IS a bug in Emacs and it's very specific, thus maybe hard to reproduce. Listen up: Emacs does honor the -geometry IF the size specified would not lead to a window bigger than the screen. For this Emacs seems to compute the size of the edit area + size of the toolbar. Now IF you have '(tool-bar-mode nil) ;; inhibit toolbar icons in your .emacs file, Emacs STILL seems to take the size of the tool.bar into account. That is the reason, why it seems to "stop" drawing the window size just a few lines less of what would be possible given current Y resolution and font size. In my case, this magic is 85 lines on 1200 and fn 6x13 (87 should be possible. And 137 on 1200 and fn 5x8 (~140 should be possible). So the bug seems to be actually: Emacs takes for window size computations the tool-bar into account even if it is disabled. Phew. Are you still with me?
(In reply to comment #7) > Emacs takes for window size computations the tool-bar into account even if it > is disabled. Yes, it is a bug well-documented in the Emacs manual. ;-) See Appendix C.9 "Options for Window Size and Position". Basically, it says that you should set the Emacs.toolBar X resource to 0 to suppress the resizing. If this qualifies as a bug may be arguable (but I agree that the behaviour is confusing at least). In any case, it is nothing that we could/should fix at the distro level, therefore resolving as UPSTREAM.
