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

Previous Next

Package: emacs;

Reported by: Kaushal <kaushal.modi <at> gmail.com>

Date: Fri, 17 Apr 2015 18:04:01 UTC

Severity: normal

Found in version 25.0.50

Done: Kaushal Modi <kaushal.modi <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20361 in the body.
You can then email your comments to 20361 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#20361; Package emacs. (Fri, 17 Apr 2015 18:04:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kaushal <kaushal.modi <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 17 Apr 2015 18:04:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kaushal <kaushal.modi <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.50; Frame position change using set-frame-position does not
 stick (Linux)
Date: Fri, 17 Apr 2015 18:03:38 +0000
[Message part 1 (text/plain, inline)]
*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))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#20361; Package emacs. (Sun, 19 Apr 2015 01:55:02 GMT) Full text and rfc822 format available.

Message #8 received at 20361 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Kaushal <kaushal.modi <at> gmail.com>
Cc: 20361 <at> debbugs.gnu.org
Subject: Re: bug#20361: 25.0.50;
 Frame position change using set-frame-position does not stick (Linux)
Date: Sat, 18 Apr 2015 21:54:19 -0400
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.





Reply sent to Kaushal Modi <kaushal.modi <at> gmail.com>:
You have taken responsibility. (Mon, 14 Sep 2015 20:46:02 GMT) Full text and rfc822 format available.

Notification sent to Kaushal <kaushal.modi <at> gmail.com>:
bug acknowledged by developer. (Mon, 14 Sep 2015 20:46:02 GMT) Full text and rfc822 format available.

Message #13 received at 20361-done <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>, 20361-done <at> debbugs.gnu.org
Subject: Re: bug#20361: 25.0.50; Frame position change using
 set-frame-position does not stick (Linux)
Date: Mon, 14 Sep 2015 20:45:30 +0000
[Message part 1 (text/plain, inline)]
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 <at> 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.
>
>
[Message part 2 (text/html, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 13 Oct 2015 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 310 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.