[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27923: 24.3; -iconic switch screws up geometry
From: |
Geoff Kuenning |
Subject: |
bug#27923: 24.3; -iconic switch screws up geometry |
Date: |
Thu, 16 Nov 2017 15:16:07 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
(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.)
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 also tried removing both emacs-related and font-related
resources from the RDB, again getting the width/height
inconsistency.
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.
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.
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.
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.)
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.
Color me confused...
FWIW, when I was doing the tests below there was a brief flash
on my
screen each time I launched emacs, implying that the window is
first
mapped and then unmapped. I don't know of that's related to
the
problem.
Do the flashes occur only when you load init.el or also when
using the
--iconic --geometry 80x78+1180+0 switches only?
emacs -Q --iconic --geometry 80x78+1180+0 --font
"-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1"
This works correctly, but the geometry reported by xwininfo is
79x77+100+0 (which is related to my Emacs.geometry Xrdb setting
rather than my gnuemacs.geometry).
Do you mean that both sizes are off by one - 80/79 and 78/77 ?
What do
M-: (frame-width) RET
and
M-: (frame-height)
in such a frame give? Did you remove/comment out the resource
settings?
IIRC Emacs combines everything it finds and applies the last
settings it
read.
emacs -Q --iconic --load ~/init.el
works entirely correctly with the first init.el (including
correct X
placement).
emacs -Q --load ~/init.el
works entirely correctly with the second init.el.
So apart from the flashes these would be OK?
Also, please tell me what
your original scenario gives with the line specifying the font
setting
removed from the resource file.
That one still fails.
"still" in the sense that you get the same bad width? Does
removing the
font setting change _anything_ in the appearance of the frame?
Thanks, martin
--
Geoff Kuenning geoff@cs.hmc.edu
http://www.cs.hmc.edu/~geoff/
A programmer who can't write readable prose is as incompetent as
one
who can't produce working code.