bug#27923: 24.3; -iconic switch screws up geometry

[martin rudalics <rudalics@gmx.at>]

 > (frame-width) and (frame-height) give 80 and 78, respectively. And I
 > double-checked that xwininfo indeed says 79x77+100+0.  (This is when
 > starting with -Q, --iconic, --geometry, --font, and my default
 > resources.)

With Emacs you traditionally set (via 'set-frame-height' and
'set-frame-width') and retrieve (via 'frame-height' and 'frame-width')
the size of a somehwat fictitious area which includes one scroll bar and
fringes sometimes a toolbar and a menubar.  With GTK builds, tool- and
menubar are usually not counted so I don't understand the 78/77
difference in your case but the 80/79 difference should be explainable
by the presence of a scrollbar.  All values are rounded to the frame's
default character size.

Usually, comparing xwininfo output with what Emacs tells you is
confusing at least.

 > If I grep all emacs-related resources from my xrdb file and reload it,
 > starting with the same command gives the same inconsistency between
 > frame-width/height and xwininfo.  Perhaps the width issue is because
 > one character space is allocated to the scrollbar?

I think so too.

 > But just to make sure we're talking about the same thing, in all of
 > these cases emacs is coming up with a correct window size after I
 > deiconify it.

I'm not sure I understand the last sentence.  Correct in the sense that
the main window displays 80x78 characters?

 > Hmmm, though...I just discovered that "emacs -Q --iconic" produces a
 > different result: it creates an 80x35 frame (79x34 according to
 > xwininfo) even when my xrdb contains both an Emacs.geometry of
 > 80x78+100+0 and a slightly conflicting gnuemacs.geometry of
 > 80x78+1180+0.  (I have no clue why I have both!)  This implies that
 > there's something in my .emacs that's relevant.

You mean there's something in your .emacs that gets you a different
height: 80/79 without loading .emacs and 35/34 with loading .emacs?

 > I did some binary searching and narrowed it down to a relatively small
 > area.  However, in the process I discovered that there must be a race,
 > because on a hunch I tried launching twice with no change in my
 > .emacs, and once was OK and once produced the narrow window.

I'm confused now - is the 35/34 above the width or the height of the
frame?

 > Anyway, I finally got down to the following two lines:
 >
 > (menu-bar-mode -1)
 > (set-default-font (x-get-resource "Font" ""))

 > With both of those present, I get the absurdly narrow frame.  If I
 > remove the first, then I get a frame that's 38x78.  If I leave the
 > first and remove the second, I get a teeny frame that's too small to
 > type in, but xwininfo reports it as 1x1 (so suppose emacs thinks it's
 > 2x2).  And if I remove both, I get a properly sized frame.  (This is
 > all with my xrdb restored, BTW.)

Sounds weird.  BTW what does evaluating (x-get-resource "Font" "")
return?

 > But that's not the strangest part.  I cut my .emacs down to JUST those
 > two lines, and things then worked fine.  More testing eventually gave me
 > the following .emacs file (this is 100% of the contents):
 >
 > (if nil
 >     (setq load-path (append
 >                      (mapcar
 >                       '(lambda (value)
 >                          (if (and (stringp value)
 >                                   (not (string-match                                  "^/usr/local/" value))
 >                                   (string-match "^/usr/" value))
 >                              (replace-match "/usr/local/" t t                             value)
 >                            value))
 >                        load-path)
 >                      load-path)))
 > (menu-bar-mode -1)
 > (set-default-font (x-get-resource "Font" ""))
 >
 > Obviously, the first bit of code doesn't get executed.  But if I remove
 > it, launching in iconic mode works!  Having it there makes stuff break.
 >
 > Note that the .emacs above is 532 bytes.  Is there an ancient 512-byte
 > buffer somewhere?  I tried replacing the "if nil" part with 512
 > semicolons, but that didn't produce an error.

We occasionally use(d) a 512 byte limit to search for the occurrence of
something in a file but I see no connection to your case.

 > Color me confused...

Maybe the best thing to do at this moment is that you try with a later
version of Emacs, 25.3 at least.  My GNU/Linux machine crashed a few
years ago and I still did not restore my older Emacs versions including
that of Emacs 24.  Also, on Windows the --iconic switch did not even
work with Emacs 24, so maybe in this area something has changed on
GNU/Linux as well.  If you upgrade, we could try to synchronize our
observations better.  Note that on GNU/Linux it's already an enormous
pain to compare the behavior of the same version of Emacs under two
different window managers.

martin