GNU bug report logs -
#20361
25.0.50; Frame position change using set-frame-position does not stick (Linux)
Previous Next
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.
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):
[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):
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):
[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.