bug#32207: 26.1; can't set window position with emacs 26.3

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

Emacs 26.1.3 on Fedora doesn't respect the position part of
the geometry given in the command line (it does respect the
width and height).  

I start two emacs sessions (as "me" and "root") and place
them on desk 1/page 1 and desk1/page 5 of my FVWM
configuration, and they both start on desk 1/page 1, at the
whim of the window manager.

I also sprinkle a few xterm around different desks/pages,
and fvwm obeys my specifications, so the change is not there.

Fails with "emacs -Q --no-loadup  --no-site-file--no-site-lisp"
and either -g, --geometry, --geometry=, -geometry, and with
no .Xdefaults or xresources.

I've been using this setup for several years and it has
worked up to emacs 25.3.


In GNU Emacs 26.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.22.30)
 of 2018-06-26 built on buildhw-10.phx2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.11906000
System Description:	Fedora release 28 (Twenty Eight)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr
 --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
 --sysconfdir=/etc --datadir=/usr/share
 --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif
 --with-jpeg --with-png --with-rsvg --with-tiff --with-xft
 --with-xpm --with-x-toolkit=gtk3 --with-gpm=no
 --with-xwidgets --with-modules
 build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF
 -O2 -g -pipe -Wall -Werror=format-security
 -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
 -fexceptions -fstack-protector-strong -grecord-gcc-switches
 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
 -mtune=generic -fasynchronous-unwind-tables
 -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS
XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > Emacs 26.1.3 on Fedora doesn't respect the position part of
 > the geometry given in the command line (it does respect the
 > width and height).

So IIUC Emacs fails to position the initial frame within a large
virtual desktop that spans several screens.  And if that virtual
desktop equals the size of your screen, there are no problems.
Correct?

Does positioning a new frame in a running Emacs session via

(make-frame '((left . x) (top . y)))

for some values of x and y fail in the same sense as with the command
line parameters?

Thanks, martin

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

> So IIUC Emacs fails to position the initial frame within a
> large virtual desktop that spans several screens.  And if
> that virtual desktop equals the size of your screen, there
> are no problems.
> Correct?

No, it fails to position the initial frame period.  I start
one emacs on the "default/initial" screen, another a few
screens away.  Neither obeys the command line position.

> Does positioning a new frame in a running Emacs session via
> (make-frame '((left . x) (top . y)))

Just tried it with x and y within the physical desktop and a
few screens away and neither worked.

However, if I kill fvwm and use make-frame, it WORKS!  Even
off screen, which I can see when I restart fvwm.

This is interesting, as I'm running the same fvwm as with
the previous emacs, where this worked.  Also xterms position
themselves properly.  Just tried glxgears, mplayer and it
works with those too.  Xv works within the physical screen,
it doesn't off-screen.

Maybe Emacs changed the way it requests the screen position
to a way that fvwm doesn't like.  I'll need to try with
another window manager.

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

> Maybe Emacs changed the way it requests the screen position
> to a way that fvwm doesn't like.  I'll need to try with
> another window manager.

If I kill fvwm and start mutter, emacs places itself properly.

Looking at fvwm's log I see this message when starting emacs:
  [fvwm.0][GetWindowSizeHints]: <<WARNING>> reason: 6: The
  hints have been ignored because the window's current size
  would have become invalid.  The new hints will become
  active when the window generates the next ConfigureRequest.

I don't remember seeing this message before.

If I turn fvwm's:
  BugOpts ExplainWindowPlacement True

When I start emacs as:
  emacs -Q -g 80x40+500+500
I get this explanation:
  [fvwm.0][__explain_placement]: placed new window 0x1800142 'emacs@...':
    initial size 764x780
    desk 0 (current desk)
    current page
    position 20 40, placed by fvwm (ignored program specified position)
      placement method: TileCascade

Similarly for -geometry 80x40+500+500, and --geometry=80x40+500+500

When I start an xterm as:
  xterm -geometry 80x40+500+500
I get this one:
  [fvwm.0][__explain_placement]: placed new window 0x1800025 'xterm':
    initial size 816x839
    desk 0 (current desk)
    current page
    position 500 500  (used user specified position)

For xterm, fvwm says "user specified", for emacs it says "program specified". 
This and the IgnoredHints above may have something to do with it.

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > No, it fails to position the initial frame period.  I start
 > one emacs on the "default/initial" screen, another a few
 > screens away.  Neither obeys the command line position.

I was confused by your earlier text ...

 >> them on desk 1/page 1 and desk1/page 5 of my FVWM
 >> configuration, and they both start on desk 1/page 1, at the

... and so I now presume that the desk/page specifications have no
relevance to the problem.  Right?

 >> Does positioning a new frame in a running Emacs session via
 >> (make-frame '((left . x) (top . y)))
 >
 > Just tried it with x and y within the physical desktop and a
 > few screens away and neither worked.

Aha.  So let's concentrate on 'make-frame' from a running Emacs
session to avoid dealing with the startup rigmarole.

 > However, if I kill fvwm and use make-frame, it WORKS!  Even
 > off screen, which I can see when I restart fvwm.
 >
 > This is interesting, as I'm running the same fvwm as with
 > the previous emacs, where this worked.  Also xterms position
 > themselves properly.  Just tried glxgears, mplayer and it
 > works with those too.  Xv works within the physical screen,
 > it doesn't off-screen.
 >
 > Maybe Emacs changed the way it requests the screen position
 > to a way that fvwm doesn't like.  I'll need to try with
 > another window manager.

We already have a new window manager dependent issue with Bug#31745.
Just that fvwm is not listed there IIRC.

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > Looking at fvwm's log I see this message when starting emacs:
 >    [fvwm.0][GetWindowSizeHints]: <<WARNING>> reason: 6: The
 >    hints have been ignored because the window's current size
 >    would have become invalid.

This hints at yet another sizing problem.  What happens when you
specify size _and_ position via say

(make-frame '((top . 100) (left . 100) (width . 50) (height . 10)))

 > The new hints will become
 >    active when the window generates the next ConfigureRequest.
 >
 > I don't remember seeing this message before.
 >
 > If I turn fvwm's:
 >    BugOpts ExplainWindowPlacement True
 >
 > When I start emacs as:
 >    emacs -Q -g 80x40+500+500
 > I get this explanation:
 >    [fvwm.0][__explain_placement]: placed new window 0x1800142 'emacs@...':
 >      initial size 764x780
 >      desk 0 (current desk)
 >      current page
 >      position 20 40, placed by fvwm (ignored program specified position)
 >        placement method: TileCascade

Can you try with "Tile Manual Placement" instead of "Tile Cascade"?  I
suppose that Tile Cascade means that the window manager is allowed to
(or even should) override the application's request.

 > Similarly for -geometry 80x40+500+500, and --geometry=80x40+500+500
 >
 > When I start an xterm as:
 >    xterm -geometry 80x40+500+500
 > I get this one:
 >    [fvwm.0][__explain_placement]: placed new window 0x1800025 'xterm':
 >      initial size 816x839
 >      desk 0 (current desk)
 >      current page
 >      position 500 500  (used user specified position)
 >
 > For xterm, fvwm says "user specified", for emacs it says "program specified".
 > This and the IgnoredHints above may have something to do with it.

Then maybe

(make-frame '((user-position . t) (top . 100) (left . 100)))

will do?

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[Henrique Martins]

> What happens when you specify size _and_ position via say
> (make-frame '((top . 100) (left . 100) (width . 50) (height . 10)))

Same thing.  Size is obeyed, position is ignored.

> Can you try with "Tile Manual Placement" instead of "Tile
> Cascade"?

Doesn't work too well, as it results in the I need to
position every window manually.  (Fvwm puts up a wire frame
for me drag.)

> (make-frame '((user-position . t) (top . 100) (left . 100)))

This works fine.  Fvwm now claims "used user specified position"

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 >> Can you try with "Tile Manual Placement" instead of "Tile
 >> Cascade"?
 >
 > Doesn't work too well, as it results in the I need to
 > position every window manually.  (Fvwm puts up a wire frame
 > for me drag.)

But the Emacs window gets placed as intended.  Right?

 >> (make-frame '((user-position . t) (top . 100) (left . 100)))
 >
 > This works fine.  Fvwm now claims "used user specified position"

Good.  Can you make it work for the initial frame as well?

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

>>> Can you try with "Tile Manual Placement" instead of "Tile
>>> Cascade"?
>> Doesn't work too well, as it results in the I need to
>> position every window manually.  (Fvwm puts up a wire frame
>> for me drag.)

> But the Emacs window gets placed as intended.  Right?

No, random position or top-left at the middle of the screen,
can't remember exactly.  And it still requires me to place
the window, which is not going to work very well if I want
to move it several screens over.

>>> (make-frame '((user-position . t) (top . 100) (left . 100)))
>> This works fine.  Fvwm now claims "used user specified position"

> Good.  Can you make it work for the initial frame as well?

How do I make it work for the initial frame, under "emacs -Q"?

I know (and knew) I can customize my initialization to place
the windows where I want them, or give them different titles
and have FVWM place them according to it, that's not the
point.

The question was more why can't emacs 26 obey the CLI argument,
as documented in the man page, when emacs 25 could.

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 >>>> (make-frame '((user-position . t) (top . 100) (left . 100)))
 >>> This works fine.  Fvwm now claims "used user specified position"
 >
 >> Good.  Can you make it work for the initial frame as well?
 >
 > How do I make it work for the initial frame, under "emacs -Q"?
 >
 > I know (and knew) I can customize my initialization to place
 > the windows where I want them, or give them different titles
 > and have FVWM place them according to it, that's not the
 > point.

And that initialization works for you without having to resort to the
'user-position' parameter?

 > The question was more why can't emacs 26 obey the CLI argument,
 > as documented in the man page, when emacs 25 could.

I couldn't tell.  If you run Emacs 25 and 26 in parallel on the same
system you could try to debug the parts where the WM hints are
processed and look whether these versions do anything differently.
Otherwise, you would have to bisect your Emacs to find out.

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

> I couldn't tell.  If you run Emacs 25 and 26 in parallel...

Compiled 25 and ran "emacs -Q -g ...'.  It places the window
fine, but ...

Shell warnings:
---------------
(emacs:23708): Gtk-WARNING **: 10:59:27.659:
  gtk_window_parse_geometry() called on a window with no
  visible children; the window should be set up before
  gtk_window_parse_geometry() is called.

Fvwm warnings (some duplicated for some reason):
------------------------------------------------
[fvwm.0][__explain_placement]: placed new window 0x600122 'emacs@...':
  initial size 404x420
  desk 0 (current desk)
  current page
  position 400 400  (used user specified position)

[fvwm.0][GetWindowSizeHints]: <<WARNING>> reason: 6: The hints have been ignored because the window's current size would have become invalid.  The new hints will become active when the window generates the next ConfigureRequest.

[fvwm.0][GetWindowSizeHints]: <<WARNING>> The application window (id 0x600122)
  "emacs@..." has broken size hints (inconsistent with current size).
    fvwm is ignoring those hints.    hint override = 0, flags = 350
  min_width = 41, min_height = 84, max_width = 41, max_height = 84
  width_inc = 9, height_inc = 18
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 41, base_height = 84
  win_gravity = 1

    If you are having a problem with the application, send a bug report
    with this message included to the application owner.
    There is no need to notify fvwm-workers@fvwm.org.

[fvwm.0][GetWindowSizeHints]: <<WARNING>> reason: 6: The hints have been ignored because the window's current size would have become invalid.  The new hints will become active when the window generates the next ConfigureRequest.

[fvwm.0][GetWindowSizeHints]: <<WARNING>> The application window (id 0x600122)
  "emacs@..." has broken size hints (inconsistent with current size).
    fvwm is ignoring those hints.    hint override = 0, flags = 350
  min_width = 41, min_height = 84, max_width = 41, max_height = 84
  width_inc = 9, height_inc = 18
  min_aspect = 0/0, max_aspect = 0/0
  base_width = 41, base_height = 84
  win_gravity = 1

    If you are having a problem with the application, send a bug report
    with this message included to the application owner.
    There is no need to notify fvwm-workers@fvwm.org.


Thus the position and size are fine, but it does generate a
lot of warnings!

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > Compiled 25 and ran "emacs -Q -g ...'.

What are the -g specifications?

 > It places the window
 > fine, but ...
 >
 > Shell warnings:
 > ---------------
 > (emacs:23708): Gtk-WARNING **: 10:59:27.659:
 >    gtk_window_parse_geometry() called on a window with no
 >    visible children; the window should be set up before
 >    gtk_window_parse_geometry() is called.

This is to be expected (see Bug#25851 for further details) and should
have been solved for Emacs 26.

 > Fvwm warnings (some duplicated for some reason):
 > ------------------------------------------------
 > [fvwm.0][__explain_placement]: placed new window 0x600122 'emacs@...':
 >    initial size 404x420
 >    desk 0 (current desk)
 >    current page
 >    position 400 400  (used user specified position)
 >
 > [fvwm.0][GetWindowSizeHints]: <<WARNING>> reason: 6: The hints have been ignored because the window's current size would have become invalid.  The new hints will become active when the window generates the next ConfigureRequest.
 >
 > [fvwm.0][GetWindowSizeHints]: <<WARNING>> The application window (id 0x600122)
 >    "emacs@..." has broken size hints (inconsistent with current size).
 >      fvwm is ignoring those hints.    hint override = 0, flags = 350
 >    min_width = 41, min_height = 84, max_width = 41, max_height = 84
 >    width_inc = 9, height_inc = 18
 >    min_aspect = 0/0, max_aspect = 0/0
 >    base_width = 41, base_height = 84
 >    win_gravity = 1
[...]
 >
 > Thus the position and size are fine, but it does generate a
 > lot of warnings!

I have no idea what kind of "inconsistency" fvwm means here.  It is
possible that 18 * 84 which gives 1512 pixels + 400 which gives 1912
pixels is too high for your screen.

Anyway, it seems that Emacs 25 while coming up with the intended
position/size does not behave correctly either.  Let's do away with
-g and resources for the moment and try starting Emacs as follows:

emacs -Q --eval "(setq initial-frame-alist '((width . 41) (height . 84) (left . 400) (top . 400)))"

Do Emacs 25 and Emacs 26 behave differently and are there any
warnings?

Thanks, martin

bug#32207: 26.1; can't set window position with emacs 26.3

[Henrique Martins]

>> Compiled 25 and ran "emacs -Q -g ...'.
>> It places the window fine
> What are the -g specifications?

emacs -Q -g 40x20+400+400

> It is possible that 18 * 84 which gives 1512 pixels + 400
> which gives 1912 pixels is too high for your screen.

The created frame is well within my 1920x1080 screen

> Let's do away with -g and resources for the moment and try
> starting Emacs as follows:
>
> emacs -Q --eval "(setq initial-frame-alist '((width . 41) (height . 84) (left . 400) (top . 400)))"

I used
  emacs -Q --eval "(setq initial-frame-alist '((width . 40) (height . 20) (left . 400) (top . 400)))"
to match the above.

With Emacs 25 it ends up in the correct position, but sizes
are messed up. The initial scratch window occupies some top
left portion of the window, with matching size menubars and
scrollbars in the middle of the window :-) and rest of frame
blank.

Emacs 26 works perfectly! even with off-screen positions.

I'll added this to my .xclients script (though -g ought to
work) and will check next time I need to restart X.

-- Henrique

PS: Adding "(user-position . t)" to the -F argument of calls
to emacsclient to place frames in my other three screens,
seems to also put them where I want them too.

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > I used
 >    emacs -Q --eval "(setq initial-frame-alist '((width . 40) (height . 20) (left . 400) (top . 400)))"
 > to match the above.
[...]
 > Emacs 26 works perfectly! even with off-screen positions.

Does that work _without_ specifying 'user-position'?

 > I'll added this to my .xclients script (though -g ought to
 > work) and will check next time I need to restart X.

It seems we have to add a 'user-position' and/or 'user-size'
specification when parsing geometry specifications.  I have no idea
what happens when -g and X resources get mixed.  Does -g work when you
specify a non-nil 'user-position' in your X resources file?

Also as far as resources are concerned we automatically add a
'user-position' and a 'user-size' parameter when a 'top' or 'left'
resource has been specified.  We do nothing when just a 'width' or
'height' resource has been specified.  I don't understand the
rationale of that and it never has been explained anywhere.

 > PS: Adding "(user-position . t)" to the -F argument of calls
 > to emacsclient to place frames in my other three screens,
 > seems to also put them where I want them too.

Hopefully.

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[emacs]

>>    emacs -Q --eval "(setq initial-frame-alist '((width . 40) (height . 20) (left . 400) (top . 400)))"
>> Emacs 26 works perfectly! even with off-screen positions.
> Does that work _without_ specifying 'user-position'?

Yes, though I should qualify the "perfectly!" above.
- there is an initial frame that seems to be placed by fvwm,
  at a position of the window manager's choice
- the initial frame is then moves to the position specified
  in the command line.
- the moves comes almost immediately after the intial
  placement, resulting in a flashing effect.

> Does -g work when you specify a non-nil 'user-position' in
> your X resources file?

Can't get emacs 25 or 26 to obey resources.

I've tried by editing my files, xrdb'ing, and running
  emacs -Q --xrm='emacs.geometry=WxH'
the initial frame always comes up as 79x35

-- Henrique

bug#32207: 26.1; can't set window position with emacs 26.3

[martin rudalics]

 > Yes, though I should qualify the "perfectly!" above.
 > - there is an initial frame that seems to be placed by fvwm,
 >    at a position of the window manager's choice
 > - the initial frame is then moves to the position specified
 >    in the command line.
 > - the moves comes almost immediately after the intial
 >    placement, resulting in a flashing effect.

The initial frame serves to display any messages that might be
produced when evaluating your .emacs or init.el file.

With Emacs 27 you can put the 'initial-frame-alist' specification into
an early-init.el file which is loaded before the initial frame is made
by the window system and gets the parameters applied right there.  I
doubt that this will always make correct geometry calculations but the
flashing effect should disappear.

martin

bug#32207: 26.1; can't set window position with emacs 26.3

[Elof Ofel]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

This is not a contributon to the above discussion but another workaround than using
emacs --eval "(setq initial-frame-alist '((width . 40) (height . 20) (left . 400) (top . 400)))"


I too suffered exactly the same position/placement problem when I upgraded my Debian 9 to Debian 10, with my old fvwm-configuration that has worked for a decade.

My workaround is to use emacs-lucid instead of emacs-gtk.
In emacs-lucid the window placement is working fine.
Also, as a positive side-effect, the emacs-lucid window is updated at lightning speed when I switch desktops, while the emacs-gtk window is first updating the window and then re-draw the text in the frame, generating a very noticeable motion on the screen.

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]