bug#20361: 25.0.50; Frame position change using set-frame-position does not stick (Linux)

bug#20361: 25.0.50; Frame position change using set-frame-position does not stick (Linux)

[Kaushal]

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

*As of writing this, I was using emacs 25 built on April 16 2015 on RHEL
5.10, GTK+ version 2.10.4, Gnome 2.16.0.*

## Issue

I am able to change the frame position using `set-frame-position`. But the
moment I use a function which uses `read-from-minibuffer`, the frame
restores its position to where it was set using the mouse.

I have seen this issue since emacs 24.3 (or probably even before that?) and
am still seeing it in the latest build of emacs from its master branch.

## How to replicate this problem?

Here's a test function to help you replicate this problem.

    (defun my/alter-frame-pos ()
      (interactive)
      (set-frame-position nil 100 100)) ; pixels x y from upper left

1. Launch `emacs -Q`.
2. Eval the above function in the \*scratch\* buffer.
3. Position the frame to any random location **using** the mouse
4. `M-x my/alter-frame-pos`. You should see the frame jump to (100,100)
pixel location.
5. `M-x find-file` or `C-x C-f` (this is one of the functions that uses
`read-from-minibuffer`)
6. The frame will jump back to wherever you set it using the mouse!

So basically my frame altering elisp snippet is useless as I have to use
the mouse to make the position stick.

I tried edebug but I couldn't go further as `read-from-minibuffer` is in C
and I can't figure out how mouse based frame dragging sets its position.

I even tried the below but that did not help:

    (defun my/alter-frame-pos ()
      (interactive)
      (set-frame-parameter nil 'user-position t)
      (set-frame-position nil 100 100)) ; pixels x y from upper left

For clarification, the `set-frame-position` is successfully able to change
the frame position regardless of the `user-position` parameter value. But
the moment I use `C-x C-f`, the position resets to where I had set the
frame using the mouse.

It's as if the position referenced by the C function `read-from-minibuffer`
gets updated only when I use mouse to move the frame, but not when I use
the `set-frame-position` function.

In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.10.4)
 of 2015-04-16 on ...
Repository revision: d4b44a07a75666177f8684876c7337c0b91a95da
Windowing system distributor `The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Client release 5.10 (Tikanga)

Configured using:
 `configure --prefix=/home/kmodi/usr_local/apps/emacs/master
 CPPFLAGS=-fgnu89-inline'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Memory information:
((conses 16 813121 54174)
 (symbols 48 57811 0)
 (miscs 40 607 510)
 (strings 32 202492 24583)
 (string-bytes 1 8088748)
 (vectors 16 103562)
 (vector-slots 8 2166557 19181)
 (floats 8 10742 472)
 (intervals 56 2627 181)
 (buffers 976 22)
 (heap 1024 208649 3092))

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

bug#20361: 25.0.50; Frame position change using set-frame-position does not stick (Linux)

[Glenn Morris]

Kaushal wrote:

>     (defun my/alter-frame-pos ()
>       (interactive)
>       (set-frame-position nil 100 100)) ; pixels x y from upper left
>
> 1. Launch `emacs -Q`.
> 2. Eval the above function in the \*scratch\* buffer.
> 3. Position the frame to any random location **using** the mouse
> 4. `M-x my/alter-frame-pos`. You should see the frame jump to (100,100)
> pixel location.
> 5. `M-x find-file` or `C-x C-f` (this is one of the functions that uses
> `read-from-minibuffer`)
> 6. The frame will jump back to wherever you set it using the mouse!

That sounds very odd.
FWIW, I cannot reproduce this on Debian testing or RHEL7.

bug#20361: 25.0.50; Frame position change using set-frame-position does not stick (Linux)

[Kaushal Modi]

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

This issue seemed to solely occur due to some odd configuration on my RHEL
5 system.

On RHEL 6, I cannot recreate this problem. (More info on my system config
where this issue went away: http://emacs.stackexchange.com/a/16613/115 )

So closing this issue.

On Sat, Apr 18, 2015 at 9:54 PM Glenn Morris <rgm@gnu.org> wrote:

> Kaushal wrote:
>
> >     (defun my/alter-frame-pos ()
> >       (interactive)
> >       (set-frame-position nil 100 100)) ; pixels x y from upper left
> >
> > 1. Launch `emacs -Q`.
> > 2. Eval the above function in the \*scratch\* buffer.
> > 3. Position the frame to any random location **using** the mouse
> > 4. `M-x my/alter-frame-pos`. You should see the frame jump to (100,100)
> > pixel location.
> > 5. `M-x find-file` or `C-x C-f` (this is one of the functions that uses
> > `read-from-minibuffer`)
> > 6. The frame will jump back to wherever you set it using the mouse!
>
> That sounds very odd.
> FWIW, I cannot reproduce this on Debian testing or RHEL7.
>
>

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