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

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

[Geoff Kuenning]

In 24.3.1, starting emacs with the "-iconic" switch causes the main
emacs window to be sized to the width of the icon rather than the width
specified in the X resource database.  Interestingly, the height is
still correct.  Compare the window created by:

    $ emacs &

with the one from:

    $ emacs -iconic &

On my system, the output for "xrdb -query | grep -i emacs" is:

gnuemacs.geometry:      80x78+1180+0
Emacs.Font:     -misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1
gnuemacs*cursorColor:   red
lemacs*cursorColor:     red

(I realize that some of these entries are obsolete...)


In GNU Emacs 24.3.1 (x86_64-suse-linux-gnu, GTK+ Version 3.20.10)
 of 2017-07-05 on cloud131
Windowing system distributor `The X.Org Foundation', version 11.0.11803000
System Description:	openSUSE Leap 42.2

Configured using:
 `configure '--with-pop' '--without-hesiod' '--with-kerberos'
 '--with-kerberos5' '--with-xim' '--with-wide-int' '--enable-autodepend'
 '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info'
 '--datadir=/usr/share' '--localstatedir=/var'
 '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x'
 '--with-sound' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif'
 '--with-png' '--with-rsvg' '--with-dbus' '--without-gpm'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 '--x-includes=/usr/include' '--x-libraries=/usr/lib64' '--with-xft'
 '--with-libotf' '--with-m17n-flt' '--build=x86_64-suse-linux'
 'build_alias=x86_64-suse-linux' 'CFLAGS=-fmessage-length=0
 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector
 -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE -pipe
 -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -Wno-unprototyped-calls -fno-optimize-sibling-calls
 -DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 '
 'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521''

Important settings:
  value of $LC_ALL: en_US.utf-8
  value of $LC_COLLATE: C
  value of $LC_NUMERIC: POSIX
  value of $LANG: en_US.utf-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  desktop-save-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill

Recent input:
M-x e m a c s - b u <tab> <tab> <tab> C-g M-x a p r 
o p o s <return> b u g <return> C-x o C-v C-v C-v C-v 
C-x 0 M-x r e p o r t <tab> <return>

Recent messages:
Loading `uniquify': old-style backquotes detected!
PGP version set to 5.0.
Setting up indent for shell type sh
setting up indent stuff
Indentation variables are now local.
Indentation setup for shell type sh
Note: file is write protected
Wrote /home/geoff/.emacs.desktop.lock
Desktop: 27 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit

Load-path shadows:
/home/geoff/lib/notes/notes-first hides ~geoff/elisp/notes-first
/home/geoff/lib/notes/notes-xemacs hides ~geoff/elisp/notes-xemacs
/home/geoff/lib/notes/notes-mode hides ~geoff/elisp/notes-mode
/home/geoff/lib/notes/notes-index-mode hides ~geoff/elisp/notes-index-mode
/home/geoff/lib/notes/notes-variables hides ~geoff/elisp/notes-variables
/home/geoff/lib/notes/notes-url hides ~geoff/elisp/notes-url
/home/geoff/lib/notes/notes-emacs hides ~geoff/elisp/notes-emacs
/home/geoff/lib/notes/notes-aux hides ~geoff/elisp/notes-aux
/home/geoff/lib/notes/notes-bootstrap hides ~geoff/elisp/notes-bootstrap
/usr/local/share/emacs/site-lisp/rep-debugger hides /usr/share/emacs/site-lisp/rep-debugger
/usr/share/emacs/site-lisp/lilypond-init hides /usr/share/emacs/site-lisp/site-start.d/lilypond-init
/usr/share/emacs/site-lisp/flim/md5 hides /usr/share/emacs/site-lisp/w3/md5
/usr/share/emacs/site-lisp/devices hides /usr/share/emacs/site-lisp/w3/devices
/usr/share/emacs/site-lisp/suse-start-xslide hides /usr/share/emacs/site-lisp/xslide/suse-start-xslide
~geoff/elisp/uniquify hides /usr/share/emacs/24.3/lisp/uniquify
~geoff/elisp/remember/remember hides /usr/share/emacs/24.3/lisp/textmodes/remember

Features:
(shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 epg-config
mm-view mml-smime smime password-cache dig gnus-sum nnoo gnus-group
gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range
gnus-win gnus gnus-ems nnheader gnus-util wid-edit emacsbug message idna
mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-mode apropos sh-script smie executable bibtex
desktop mailcap org byte-opt warnings bytecomp byte-compile cconv advice
help-fns cl-lib advice-preload ob-tangle ob-ref ob-lob ob-table
org-footnote org-src ob-comint ob-keys org-pcomplete org-list org-faces
org-entities noutline outline easy-mmode org-version ob-emacs-lisp ob
org-compat org-macs ob-eval org-loaddefs format-spec find-func cal-menu
calendar cal-loaddefs remember paren mailcrypt rfc822 easymenu
notes-variables notes-emacs uniquify server pabbrev tex-mode compile
shell pcomplete comint ansi-color ring time-date delsel lpr tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

-- 
    Geoff Kuenning   geoff@cs.hmc.edu   http://www.cs.hmc.edu/~geoff/

An undocumented program is as useless as a non-working one.

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

[martin rudalics]

 > In 24.3.1, starting emacs with the "-iconic" switch causes the main
 > emacs window to be sized to the width of the icon rather than the width
 > specified in the X resource database.  Interestingly, the height is
 > still correct.  Compare the window created by:
 >
 >      $ emacs &
 >
 > with the one from:
 >
 >      $ emacs -iconic &
 >
 > On my system, the output for "xrdb -query | grep -i emacs" is:
 >
 > gnuemacs.geometry:      80x78+1180+0
 > Emacs.Font:     -misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1
 > gnuemacs*cursorColor:   red
 > lemacs*cursorColor:     red
 >
 > (I realize that some of these entries are obsolete...)

Thanks for the report; apologizes for the late response.  Are you sure
that your display is at least 1900 pixels wide?  If so, then when with
emacs -Q you evaluate the form

(setq default-frame-alist
       '((width . 80)
	(height . 78)
	(left . 1180)
	(font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1")
	(visibility . icon)))

and subsequently do C-x 5 2 and deiconify the new frame, does it have
the desired properties?

Thanks, martin

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

[martin rudalics]

 > My display is 3840x1200.  I'm pretty sure that's wider than 1900. ;-)

That's bad because it means we are in the area of one of the most
elusive bugs I've seen over the past years.  Your scenario has been
already reported (with .emacs instead of using a resource file) as

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24526

and probably also here

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25943

The underlying problem seems to be that the geometry settings for an
invisible or iconified frame get lost somewhere and are not processed
(or even reverted) when the frame is made visible.  On Windows, the bug
manifests itself when specifying the geometry in the init file but not
when the geometry is specified as command argument.  On GNU/Linux the
bug seems to depend on the window manager - I can't reproduce it here on
Debian using Xfwm.

 > In your suggested test, yes, setting default-frame-alist and then
 > creating a new iconified frame does indeed give me the desired
 > properties.

Which suggests that creating the initial frame with its dimensions is
the culprit.  What does M-: RET (frame-width) RET of the deformed frame
print?

 > Please let me know if there are any additional tests you'd like me to perform.

There are.  First I would like to see whether the bug occurs with all
possible invocation scenarios in the same way.  Please invoke Emacs as

emacs -Q --iconic --geometry 80x78+1180+0 --font "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1"

as

emacs -Q --iconic --load ~/init.el

with init.el specified as

(setq default-frame-alist
       '((width . 80)
	(height . 78)
	(left . 1180)
	(font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1")))

and as

emacs -Q --load ~/init.el

with init.el specified as

(setq default-frame-alist
       '((width . 80)
	(height . 78)
	(left . 1180)
	(font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1")
	(visibility . icon)))

and tell me whether the results are the same.  Also, please tell me what
your original scenario gives with the line specifying the font setting
removed from the resource file.

Thanks, martin

PS: Please keep 27923@debbugs.gnu.org CC'd

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

[Geoff Kuenning]

Hi, Martin,

I apologize profusely for my unacceptably long delay in answering 
your questions; your message slipped by me and I only found it 
when I was cleaning up old emails.

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.

> 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).

> 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.

> 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.

>> My display is 3840x1200.  I'm pretty sure that's wider than 
>> 1900. ;-)
>
> That's bad because it means we are in the area of one of the 
> most
> elusive bugs I've seen over the past years.  Your scenario has 
> been
> already reported (with .emacs instead of using a resource file) 
> as
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24526
>
> and probably also here
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25943
>
> The underlying problem seems to be that the geometry settings 
> for an
> invisible or iconified frame get lost somewhere and are not 
> processed
> (or even reverted) when the frame is made visible.  On Windows, 
> the bug
> manifests itself when specifying the geometry in the init file 
> but not
> when the geometry is specified as command argument.  On 
> GNU/Linux the
> bug seems to depend on the window manager - I can't reproduce it 
> here on
> Debian using Xfwm.
>
>> In your suggested test, yes, setting default-frame-alist and 
>> then
>> creating a new iconified frame does indeed give me the desired
>> properties.
>
> Which suggests that creating the initial frame with its 
> dimensions is
> the culprit.  What does M-: RET (frame-width) RET of the 
> deformed frame
> print?
>
>> Please let me know if there are any additional tests you'd like 
>> me to perform.
>
> There are.  First I would like to see whether the bug occurs 
> with all
> possible invocation scenarios in the same way.  Please invoke 
> Emacs as
>
> emacs -Q --iconic --geometry 80x78+1180+0 --font 
> "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1"
>
> as
>
> emacs -Q --iconic --load ~/init.el
>
> with init.el specified as
>
> (setq default-frame-alist
>       '((width . 80)
> 	(height . 78)
> 	(left . 1180)
> 	(font 
> . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1")))
>
> and as
>
> emacs -Q --load ~/init.el
>
> with init.el specified as
>
> (setq default-frame-alist
>       '((width . 80)
> 	(height . 78)
> 	(left . 1180)
> 	(font 
> . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1")
> 	(visibility . icon)))
>
> and tell me whether the results are the same.  Also, please tell 
> me what
> your original scenario gives with the line specifying the font 
> setting
> removed from the resource file.
>
> Thanks, martin
>
> PS: Please keep 27923@debbugs.gnu.org CC'd
>

-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

An Internet that is not Open represents a potentially grave risk 
to
freedoms of many sorts -- freedom of speech and other civil 
liberties,
freedom of commerce, and more -- and that openness is what we must 
so
diligently work to both preserve and expand.
		-- Lauren Weinstein

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

[martin rudalics]

 > 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

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

[Geoff Kuenning]

Caveat: the testing has all been on my desktop at work, so I can't 
run new tests at this instant and am working from memory.

> Do the flashes occur only when you load init.el or also when 
> using the
> --iconic --geometry 80x78+1180+0 switches only?

My memory is that they happen at all times when using --iconic.

>>> 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

Yes, the size should be 80x78 and instead comes up as 79x77. 
Weird, huh?

> M-: (frame-width) RET
>
> and
>
> M-: (frame-height)

I'll try to remember to try those tomorrow.

> 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.

When running without -Q, I used grep to remove resource settings 
from my master parameter file and reloaded that into X11 with 
xrdb.

>>> 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?

Yes.  And I never would have noticed the flashes if I hadn't been 
testing; they're under 1/10 second and happen when I'm logging in 
every morning.

>>> 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?

Yes, the same bad width.  I'll check carefully tomorrow to see 
whether there is any frame change.
-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

Statistics don't bore people, people bore people.

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

[martin rudalics]

 >> Do you mean that both sizes are off by one - 80/79 and 78/77 ? What do
 >
 > Yes, the size should be 80x78 and instead comes up as 79x77. Weird, huh?

There might be some snafu with how to count in toolbar, menubar and
scrollbar.

 >> M-: (frame-width) RET
 >>
 >> and
 >>
 >> M-: (frame-height)
 >
 > I'll try to remember to try those tomorrow.

Please do that.  It will tell us what Emacs thinks about the "realized"
size.

martin

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

[Geoff Kuenning]

(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.

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

[Geoff Kuenning]

One other thing: I just checked the actual width of my frame by 
typing 80 characters, and it's 80 characters even though xwininfo 
is reporting 79.  So I think this is either an actual xwininfo 
bug, or a minor interaction between emacs and X that causes the 
character size of a pixel window to be seen slightly incorrectly.

>>> Do you mean that both sizes are off by one - 80/79 and 78/77 ? 
>>> What do
>>
>> Yes, the size should be 80x78 and instead comes up as 
>> 79x77. Weird, huh?
>
> There might be some snafu with how to count in toolbar, menubar 
> and
> scrollbar.
>
>>> M-: (frame-width) RET
>>>
>>> and
>>>
>>> M-: (frame-height)
>>
>> I'll try to remember to try those tomorrow.
>
> Please do that.  It will tell us what Emacs thinks about the 
> "realized"
> size.
>
> martin
>

-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

The P in "PDF" is a lie.

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

[martin rudalics]

 > (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

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

[martin rudalics]

 > One other thing: I just checked the actual width of my frame by typing
 > 80 characters, and it's 80 characters even though xwininfo is
 > reporting 79.  So I think this is either an actual xwininfo bug, or a
 > minor interaction between emacs and X that causes the character size
 > of a pixel window to be seen slightly incorrectly.

The inherent idea here is that when Emacs comes up with a one-window
frame that does not contain a minibuffer window, the sizes specified by
'frame-width' and 'frame-height' match the maximum number of characters
on one line and the maximum number of lines that can be displayed
in that frame's window.  For each and every build of Emacs on every
platform and regardless of which other GUI elements are present.

So, for example, when you add/remove scrollbars or change the default
font of a frame, Emacs usually asks the window manager to change the
size of the (window manager) window to keep the number of lines/columns
of the frame constant.

martin

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

[Geoff Kuenning]

>> 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?

Yes, that's right.  Whenever I refer to "works right" I mean that 
if I launch with -iconic and then de-iconify, I get a window 
that's the size I expect.

>> 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 didn't identify the source of the problem, but yes.

BTW, that email was a bit of a stream of consciousness: I was 
typing it as I was doing experiments and being interrupted over 
the course of a few hours.

>
>> 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?

Sorry, bad typing on my part.  35/34 was the height.

>> 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?

I'll give that a shot tomorrow.

>> 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.

It may not happen until the Christmas break, but I'm sure I can 
manage to get the latest version installed.  It would be wonderful 
if the bug went away on its own!
-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

Substitute "damn" every time you're inclined to write "very;" your
editor will delete it and the writing will be just as it should 
be.
	-- Mark Twain

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

[martin rudalics]

 > Sorry, bad typing on my part.  35/34 was the height.
 >
 >>> 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.)

So are you getting a weird height, a weird width, independently both or
simultaneously both?

 > It may not happen until the Christmas break, but I'm sure I can manage
 > to get the latest version installed.

This would be currently 26.0.90 which also has a quite extensive set of
functions to measure frame sizes and how they developed when starting
Emacs.

 > It would be wonderful if the bug
 > went away on its own!

Do they ever?

martin

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

[Geoff Kuenning]

>> Sorry, bad typing on my part.  35/34 was the height.
>>
>>>> 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.)
>
> So are you getting a weird height, a weird width, independently 
> both or
> simultaneously both?

Sometimes normal height, tiny width (that's what prompted the 
original bug report).  Sometimes both weird height and weird 
width.  I don't think I've seen a normal width with a weird height 
but I might be misremembering.

>> It would be wonderful if the bug
>> went away on its own!
>
> Do they ever?

Heisenbugs!

More seriously, not without help from talented developers...
-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

It's is not, it isn't ain't, and it's it's, not its, if you mean 
it
is.  If you don't, it's its.  Then too, it's hers.  It isn't 
her's.  It
isn't our's either.  It's ours, and likewise yours and theirs.
                -- Oxford University Press, Edpress News

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

[Lars Ingebrigtsen]

Geoff Kuenning <geoff@cs.hmc.edu> writes:

> In 24.3.1, starting emacs with the "-iconic" switch causes the main
> emacs window to be sized to the width of the icon rather than the width
> specified in the X resource database.  Interestingly, the height is
> still correct.  Compare the window created by:
>
>     $ emacs &
>
> with the one from:
>
>     $ emacs -iconic &

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I tried reproducing this on Debian/bullseye with Gnome Shell, and I
didn't see any differences in the frame sizes here, but perhaps it's
dependent on the window manager.

Are you still seeing this problem in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Geoff Kuenning]

Well...yes and no.  The "absurdly narrow" problem is gone.  But if 
I start emacs with -iconic, the window *height* is now off (it's 
slightly too tall, by 1-2 lines, so that it goes off the screen 
since I use a full-height window).  Without -iconic it is 
correctly sized for my screen.

FWIW I use the sawfish window manager (because it's programmable 
via lisp...perhaps there are other emacs users who like lisp? 
*grin*).

> Geoff Kuenning <geoff@cs.hmc.edu> writes:
>
>> In 24.3.1, starting emacs with the "-iconic" switch causes the 
>> main
>> emacs window to be sized to the width of the icon rather than 
>> the width
>> specified in the X resource database.  Interestingly, the 
>> height is
>> still correct.  Compare the window created by:
>>
>>     $ emacs &
>>
>> with the one from:
>>
>>     $ emacs -iconic &
>
> (I'm going through old bug reports that unfortunately weren't 
> resolved
> at the time.)
>
> I tried reproducing this on Debian/bullseye with Gnome Shell, 
> and I
> didn't see any differences in the frame sizes here, but perhaps 
> it's
> dependent on the window manager.
>
> Are you still seeing this problem in recent Emacs versions?
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

One could not be a successful scientist without realizing that, in 
contrast to
the popular conception supported by newspapers and mothers of 
scientists, a
goodly number of scientists are not only narrow-minded and dull, 
but also just
stupid. -- James Watson

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Geoff Kuenning <geoff@cs.hmc.edu> writes:

> Well...yes and no.  The "absurdly narrow" problem is gone.  But if I
> start emacs with -iconic, the window *height* is now off (it's
> slightly too tall, by 1-2 lines, so that it goes off the screen since
> I use a full-height window).  Without -iconic it is correctly sized
> for my screen.

What happens if you put

  (setq frame-resize-pixelwise t)

In your early-init.el file?

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

[Lars Ingebrigtsen]

Geoff Kuenning <geoff@cs.hmc.edu> writes:

> Well...yes and no.  The "absurdly narrow" problem is gone.  But if I
> start emacs with -iconic, the window *height* is now off (it's
> slightly too tall, by 1-2 lines, so that it goes off the screen since
> I use a full-height window).  Without -iconic it is correctly sized
> for my screen.
>
> FWIW I use the sawfish window manager (because it's programmable via
> lisp...perhaps there are other emacs users who like lisp? *grin*).

Must be a window manager interaction thing -- with Gnome Shell the size
of the frame is identical whether I start with -iconic or not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[martin rudalics]

 > Well...yes and no.  The "absurdly narrow" problem is gone.  But if I
 > start emacs with -iconic, the window *height* is now off (it's
 > slightly too tall, by 1-2 lines, so that it goes off the screen since
 > I use a full-height window).  Without -iconic it is correctly sized
 > for my screen.

In which Emacs version do you see this?

martin

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

[Geoff Kuenning]

I'm running 25.3.1.

>> Well...yes and no.  The "absurdly narrow" problem is gone.  But 
>> if I
>> start emacs with -iconic, the window *height* is now off (it's
>> slightly too tall, by 1-2 lines, so that it goes off the screen 
>> since
>> I use a full-height window).  Without -iconic it is correctly 
>> sized
>> for my screen.
>
> In which Emacs version do you see this?
>
> martin
>

-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

If it's visually ugly, it's almost certainly a bad design.

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

[Lars Ingebrigtsen]

Geoff Kuenning <geoff@cs.hmc.edu> writes:

> I'm running 25.3.1.

Could you test with a recent Emacs version instead?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[martin rudalics]

 > I'm running 25.3.1.
 >
 >>> Well...yes and no.  The "absurdly narrow" problem is gone.  But if I
 >>> start emacs with -iconic, the window *height* is now off (it's
 >>> slightly too tall, by 1-2 lines, so that it goes off the screen since
 >>> I use a full-height window).  Without -iconic it is correctly sized
 >>> for my screen.
 >>
 >> In which Emacs version do you see this?

We tried to fix that in what will become Emacs 28.1.

martin

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

[Geoff Kuenning]

From Lars:

> Could you test with a recent Emacs version instead?

Unfortunately that would be pretty painful; an emacs installation 
has enough complex dependencies that replacing my distro's version 
would be risky.  I don't think I have the time right now to do 
that.

From Martin:

> We tried to fix that in what will become Emacs 28.1.

In that case, and given that it seems to work for you, I think it 
might be best to just close this old bug report as "cannot 
reproduce".  It's a small problem at worst and probably not worth 
spending a lot of your time chasing it when it might already be 
fixed.
-- 
    Geoff Kuenning   geoff@cs.hmc.edu 
    http://www.cs.hmc.edu/~geoff/

The "M" in XML stands for _markup_.  If you don't have anything
outside the angle brackets, you probably shouldn't be using XML.

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

[Lars Ingebrigtsen]

Geoff Kuenning <geoff@cs.hmc.edu> writes:

> In that case, and given that it seems to work for you, I think it
> might be best to just close this old bug report as "cannot reproduce".

OK; closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no