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 am not sure if this is a bug because I have seen this issue probably since emacs 24.3 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
- Eval the above function in the *scratch* buffer.
- Position the frame to any random location using the mouse
M-x my/alter-frame-pos. You should see the frame jump to (100,100) pixel location.
C-x C-f(this is one of the functions that uses
- 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.
Solution attempt 1
I tried using Drew's suggestion but the problem still persists.
(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
As of writing this question, I was using emacs 25 built on April 16 2015 on RHEL 5.10, GTK+ version 2.10.4, Gnome 2.16.0.
Are you able to replicate this issue?
As Drew reported, this issue is not replicated on Windows. So the problem could be specific to Linux or the flavor of Linux I am using (default Gnome that came with RHEL 5.10).
If so, is there a right way of setting the frame position using elisp?
Should this be filed as a bug report?