*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.
of 2015-04-16 on ...