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 ()
  (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.

Solution attempt 1

I tried using Drew's suggestion but the problem still persists.

(defun my/alter-frame-pos ()
  (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.


  1. 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).

  2. If so, is there a right way of setting the frame position using elisp?

  3. Should this be filed as a bug report?

    debbugs #20361


See frame parameter user-position, and the Elisp manual, node Positional Parameters.

Set parameter user-position to non-nil, to tell your window manager that the position you have moved the frame to is, in effect, a user-defined position. This suggests to the window manager not to mess with it further.

And no, I don't see that problem using your recipe. But I am using MS Windows, and the behavior for this kind of thing can be window manager-specific.

And no, this should not be filed as a bug report, I think. Whether programmatic setting of frame parameters should be considered by the window manager as having been set by the user is a choice that depends on the context.

It is the raison d'etre for parameter user-position. In some cases you do not want programmatic changes to override the position that a user might have established. In your example, suppose that, for some context, you do not want the program to override the position the user chose with the mouse.

  • Can you please provide an example of how to set the user-position parameter? It seems like I need to set that when creating a frame? Because set-frame-position does not have that argument. – Kaushal Modi Apr 17 '15 at 16:57
  • 1
    C-h f set-frame-parameter -- (set-frame-parameter nil 'user-position t). The most general function for modifying frame parameters is modify-frame-parameters. – Drew Apr 17 '15 at 16:59
  • Thanks. I tried that but that did not help. – Kaushal Modi Apr 17 '15 at 17:02
  • In that case, perhaps someone else has an explanation or suggestion. You can try reporting that as a bug, but I doubt that it will be considered such. In any case, specify your platform (window manager). Emacs cannot oblige the window manager to respect a frame position that Emacs tries to set. – Drew Apr 17 '15 at 17:04
  • 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. – Kaushal Modi Apr 17 '15 at 17:20

I will consider this as a system-specific issue.

I saw this issue on RHEL 5. But I don't see this anymore on RHEL 6.

With the emacs built from the git master branch today, M-x emacs-version returns,

GNU Emacs (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23) of 2015-09-14

lsb_release -a returns,

LSB Version: :base-4.0-amd64:base-4.0-ia32:base-4.0-noarch:core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: RedHatEnterpriseWorkstation
Description: Red Hat Enterprise Linux Workstation release 6.6 (Santiago)
Release: 6.6
Codename: Santiago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.