Frame position change using elisp not sticking

Question

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 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

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

Questions

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

Answer 1

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.

Answer 2

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 25.0.50.1 (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