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

[Geoff Kuenning <geoff@cs.hmc.edu>]

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