GNU bug report logs -
#38452
26.3; set-frame-position is slightly drifted
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38452 in the body.
You can then email your comments to 38452 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#38452; Package
emacs.
(Mon, 02 Dec 2019 03:22:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Pascal Lambrechts <pascal.lambrechts <at> uclouvain.be>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 02 Dec 2019 03:22:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
I noticed a strange behaviour with the function set-frame-position.
This happens even when starting from `emacs -q --no-site-file`
If I evaluate the following expression:
(let ((x (frame-parameter nil 'left))
(y (frame-parameter nil 'top)))
(set-frame-position nil x y))
( by C-X C-E in the file or with M-: )
the behaviour that I expect would be that the frame stays still since I use
the original left and top position to reset the position.
However the frame is slightly drifted by 10 pixel to the left and 8
pixels to the top.
If I repeat the evaluation of the expression the frame keeps moving.
More generally (set-frame-position ...) seems to be off by (-10,-8).
Best,
Pascal
-------
In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-09-16 built on lcy01-amd64-030
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.3 LTS
Recent messages:
Quit
(New file)
Making completion list...
Mark set
t
Auto-saving...done
Auto-saving...done
Mark set
Auto-saving...done
delete-backward-char: Text is read-only
Configured using:
'configure --build=x86_64-linux-gnu --prefix=/usr
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
--program-suffix=26 --with-modules --with-file-notification=inotify
--with-mailutils --with-x=yes --with-x-toolkit=gtk3 --with-xwidgets
--with-lcms2 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs26-TP6iDo/emacs26-26.3~1.git96dd019=. -fstack-protector-strong
-Wformat -Werror=format-security -no-pie' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
-no-pie''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD LCMS2
Important settings:
value of $LC_MONETARY: en_GB.UTF-8
value of $LC_NUMERIC: en_GB.UTF-8
value of $LC_TIME: en_GB.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
diff-auto-refine-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/usr/share/emacs/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/26.3/lisp/textmodes/ispell
/usr/share/emacs/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/26.3/lisp/textmodes/flyspell
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils vc-git diff-mode easymenu
easy-mmode elec-pair time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 105692 8001)
(symbols 48 21258 1)
(miscs 40 110 155)
(strings 32 30991 4008)
(string-bytes 1 812032)
(vectors 16 15327)
(vector-slots 8 525502 9320)
(floats 8 58 338)
(intervals 56 392 11)
(buffers 992 15))
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Mon, 02 Dec 2019 09:42:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> I noticed a strange behaviour with the function set-frame-position.
> This happens even when starting from `emacs -q --no-site-file`
>
> If I evaluate the following expression:
>
> (let ((x (frame-parameter nil 'left))
> (y (frame-parameter nil 'top)))
> (set-frame-position nil x y))
>
> ( by C-X C-E in the file or with M-: )
>
> the behaviour that I expect would be that the frame stays still since I use
> the original left and top position to reset the position.
> However the frame is slightly drifted by 10 pixel to the left and 8
> pixels to the top.
> If I repeat the evaluation of the expression the frame keeps moving.
>
> More generally (set-frame-position ...) seems to be off by (-10,-8).
Does
(set-frame-position nil 0 0)
work "as intended" for you? Also when evaluated two or more times in
succession?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 09:41:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 38452 <at> debbugs.gnu.org (full text, mbox):
Pascal, thanks for replying. I quote your mail in full below so it
appears that way on the bug tracker. Please always use "reply to all"
when answering, so none of your mails get lost.
> When I does
> (set-frame-position nil 0 0)
> the frame jump to the left topmost point of the avalaible screen not
> counting the dock (which on my gnome-3 desktop is on the left side) neither the
> main menu line.
> If I repeat that command the frame does not move.
>
> But in that situation I get the evaluations:
> (frame-parameter nil 'left) ==> 45
> (frame-parameter nil 'top) ==> 19
>
> Now if I evaluate (set-frame-position nil 45 19)
> the frame does not move (comparing with putting the frame at (0,0))
> and the parameters left and top keep unchanged values 45 and 19
>
> If now I evaluate:
>
> (set-frame-position nil 100 60)
> (frame-parameter nil 'left)
> (frame-parameter nil 'top)
> I get the values 90 and 52 for left and top.
>
> If reconfigure gnome so that the dock appears on the bottom of
> my screen instead of the left edge, then
> (set-frame-position nil 0 0)
> moves the frame on the leftmost position of the screen and
> (frame-parameter nil 'left) ==> (+ -10)
From this I conclude that the dock should be responsible for the
behavior you see. Which window manager do you use? What do you get
when you evaluate (display-monitor-attributes-list) in Emacs? Are
there differences in the workarea values when you evaluate that
expression with the dock on the left and at the bottom?
Also you say that
(set-frame-position nil 0 0)
and
(set-frame-position nil 45 19)
both put the frame at the same position on the screen and in both
cases the following evaluations result:
(frame-parameter nil 'left) ==> 45
(frame-parameter nil 'top) ==> 19
Is my reading of your text right? If so, then the "problems" seem to
start when the X-value is somewhere between 45 and 100 and the Y-value
between 19 and 60. Right?
Since the behavior apparently changes when you move the dock to the
bottom, the X-positioning seems clearly related to the position of the
dock. Would the Y-positioning then be related to the presence of the
main menu line (presumably on the bottom)? The one thing that
stupefies me then in either case is why the deviations are 10 and 8
pixels only. I presume that both, your dock and the menu line, are
wider.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 15:06:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 38452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
[Message part 2 (message/rfc822, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 16:00:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> As you can read in this scratch the behaviour is even more mysterious
> now. Indeed if I set the parameters and read them back by
> frame-parameter both evaluated in a enclosing progn then I get the
> expected values. But if I reread right after the parameters I get
> different values !?
My guess is that Emacs initially sets the parameter values to the
requested values and asks the window manager to apply them and later
sets the parameters to what the window manager has applied. If you
retrieve their values in between these two steps, Emacs reports the
requested and not the finally realized values. BTW, I still don't
know what your window manager is.
> pl-dock-left’s value is
> (((name . "eDP-1")
> (geometry 0 0 1920 1080)
> (workarea 55 27 1865 1053)
> (mm-size 309 174)
> (frames #<frame *Minibuf-2* 0x4e723c0> #<frame *unsent mail to martin rudalics* 0x5289930>)
> (source . "Gdk")))
>
>
> pl-dock-bottom’s value is
> (((name . "eDP-1")
> (geometry 0 0 1920 1080)
> (workarea 0 27 1920 1000)
> (mm-size 309 174)
> (frames #<frame *Minibuf-2* 0x4e723c0> #<frame *unsent mail to martin rudalics* 0x5289930>)
> (source . "Gdk")))
These values are consistent and make sense.
> In the first configuration (my laptop screen as a unique scrren) it
> seems that when the frame is at the top left corner the parameters
> take values (L=45,T=19) (which probably correspond to the width of the
> dock and height of the menu line).
Well 55 - 45 gives 10 and 27 - 19 gives 8, the values you reported in
your original report as
However the frame is slightly drifted by 10 pixel to the left and 8
pixels to the top.
If we say that the origin for things to display on screen is (-10, -8)
- something you could probably verify by moving the dock to the right
and the menu bar line to the bottom - we have a clue. Just that it
doesn't make sense to me, yet.
> If I set-frame-position at (x,y) with 0<=x<=55 and 0<=y<=27 then the
> frame does not move and the values are reset to (45,19).
> If I set-frame-position at (60,30) then the frame moved a little bit and
> the parameters evaluate to (50,22).
These fit into the picture sketched above.
> Here is a scratch file on which I did some experiment commented.
Fine exercise. Appreciated!
> Th function pl-lt is defined to easily show the values of the parameters
> left/top of the frame:
>
> ========================== SCRACTCH INTERACTIVE LISP FILE WITH EXPERMINTS ========================================
> ;; This buffer is for text that is not saved, and for Lisp evaluation.
> ;; To create a file, visit it with <open> and enter text in its buffer.
>
> ;; Experiments with set-frame-position and the result values of the parameters left and top of the frame
> ;; Each parenthesis sexp has been evaluated with C-j = eval-print-last-sexp
> (defun pl-lt ()
> "Returns a string giving the left/top positions of the current frame"
> (concat " LEFT="
> (prin1-to-string (frame-parameter nil 'left))
> " TOP="
> (prin1-to-string (frame-parameter nil 'top))))
>
>
> ;; First experiments with the laptop as only display and the gnome-3 dock on the left:
> (display-monitor-attributes-list)
> (((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053) (mm-size 309 174) (frames #<frame *scratch* 0x4e723c0> #<frame *unsent mail to martin rudalics* 0x5289930>) (source . "Gdk")))
>
>
> (set-frame-position nil 0 0)
> t
> ;; the frame is immediately below the menu line and on the immediate right of the left dock
> (pl-lt)
> " LEFT=45 TOP=19"
> (progn (set-frame-position nil 0 0) (pl-lt))
> " LEFT=0 TOP=0"
> (pl-lt)
> " LEFT=45 TOP=19"
> (set-frame-position nil 45 19)
> t
> ;; this did not move the frame: still at left corner but not overlaping the dock or menu line
> (pl-lt)
> " LEFT=45 TOP=19"
> (progn (set-frame-position nil 45 19) (pl-lt))
> " LEFT=45 TOP=19"
> (pl-lt)
> " LEFT=45 TOP=19"
> (progn (set-frame-position nil 50 25) (pl-lt))
> " LEFT=50 TOP=25"
> ;; this did not move the frame
> (pl-lt)
> " LEFT=45 TOP=19"
> ;; the parameters changed between the (pl-lt) inside the progn and after !!!
Yes. This is what I mentioned at the top of this manual.
> (progn (set-frame-position nil 55 27) (pl-lt))
> " LEFT=55 TOP=27"
> ;; this did not move the frame
> (pl-lt)
> " LEFT=45 TOP=19"
You didn't try (set-frame-position nil 56 28) here, it should move the
frame to (46, 20) IIUC ;-)
> (progn (set-frame-position nil 60 30) (pl-lt))
> " LEFT=60 TOP=30"
> ;; this moved very slight the frame away from the left-top corner
> (pl-lt)
> " LEFT=50 TOP=22"
>
>
>
> (set-frame-position nil 400 100)
> t
> ;; this moved the frame sowewhere in the middle of the screen
> (pl-lt)
> " LEFT=390 TOP=92"
> (progn (set-frame-position nil 390 92) (pl-lt))
> " LEFT=390 TOP=92"
> ;; this moved a bit the frame towars the top left corner
> (pl-lt)
> " LEFT=380 TOP=84"
>
> ;; ---------------------------
> ;; Second experiments with an external screen as single display
> (display-monitor-attributes-list)
> (((name . "DP-1-2") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053) (mm-size 598 336) (frames #<frame *scratch* 0x4e723c0> #<frame *unsent mail to martin rudalics* 0x5289930>) (source . "Gdk")))
>
> (set-frame-position nil 0 0)
> ;; the frame is immediately below the menu line and on the immediate right of the left dock
> t
> (pl-lt)
> " LEFT=45 TOP=19"
> (progn (set-frame-position nil 0 0) (pl-lt))
> " LEFT=0 TOP=0"
> (pl-lt)
>
> ;; Third experiment with a double display: internal display of laptop + external display
> ;; The external display is set as the 'primary' display and is supposed to be on the right
> ;; of the laptop display. So the menu bar and dock are only on the external display
> (display-monitor-attributes-list)
> (((name . "DP-1-2") (geometry 1920 0 1920 1080) (workarea 1920 27 1920 1053) (mm-size 598 336) (frames #<frame *scratch* 0x4e723c0> #<frame *unsent mail to martin rudalics* 0x5289930>) (source . "Gdk")) ((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 309 174) (frames) (source . "Gdk")))
> (set-frame-position nil 0 0)
> t
> ;; the frame is now in the left-top corner of the laptoop screen (no menu neither dock here)
> (pl-lt)
> " LEFT=(+ -10) TOP=(+ -8)"
> (progn (set-frame-position nil 0 0) (pl-lt))
> " LEFT=0 TOP=0"
> (pl-lt)
> " LEFT=(+ -10) TOP=(+ -8)"
So here we see that a frame that should be located at (0, 0) is moved
to (-10, -8). What does
(modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t)))
yield (to find out whether these 10/8 are due to the decorations)?
> (progn (set-frame-position nil (+ -10) (+ -8)) (pl-lt))
The doc-string of 'set-frame-position' says that
FRAME must be a live frame and defaults to the selected one. X and Y,
if positive, specify the coordinate of the left and top edge of FRAME's
outer frame in pixels relative to an origin (0, 0) of FRAME's display.
If any of X or Y is negative, it specifies the coordinates of the right
or bottom edge of the outer frame of FRAME relative to the right or
bottom edge of FRAME's display.
so you tried to move the frame to some position near the bottom right
corner of the display and these
> " LEFT=2842 TOP=288"
> ;; the previous evaluation has moved the frame on the external display close to the right corner
> (pl-lt)
> " LEFT=2832 TOP=280"
> (progn (set-frame-position nil 2832 280) (pl-lt))
> " LEFT=2832 TOP=280"
> ;; the previous sexpevaluation has moved the frame slighly to the left and top
will be as expected provided the frame size and the LEFT/TOP values
sum up accordingly.
Does anything change in general when you explicitly request a position
as with
(modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 18:19:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> My guess is that Emacs initially sets the parameter values to the
> requested values and asks the window manager to apply them and later
> sets the parameters to what the window manager has applied. If you
> retrieve their values in between these two steps, Emacs reports the
> requested and not the finally realized values.
Make sense. I inserted a (sleep-for 5) in the progn between the
set-frame-position and reading the parameters: in that case again the
value of the parameters are also changed (see the scracth eperiment at
end of mail).
> BTW, I still don't
> know what your window manager is.
I guess it is gdm3 as I entered the following commands:
M-! cat /etc/X11/default-display-manager
==> /usr/sbin/gdm3
M-! ps -e |grep gdm
==> 80 ? 00:00:00 watchdogd
829 ? 00:00:01 rsyslogd
1006 ? 00:00:00 gdm3
1119 ? 00:00:00 gdm-session-wor
1138 tty1 00:00:00 gdm-x-session
9679 ? 00:00:00 gdm-session-wor
9701 tty2 00:00:00 gdm-x-session
>
>
> If we say that the origin for things to display on screen is (-10, -8)
> - something you could probably verify by moving the dock to the right
> and the menu bar line to the bottom - we have a clue. Just that it
> doesn't make sense to me, yet.
Not sure: when I try with (undecorated.t) I get LEFT=0 TOP=(+ -30)
So the left side seems to be at 0.
>
> > If I set-frame-position at (x,y) with 0<=x<=55 and 0<=y<=27 then the
> > frame does not move and the values are reset to (45,19).
> > If I set-frame-position at (60,30) then the frame moved a little bit and
> > the parameters evaluate to (50,22).
>
> These fit into the picture sketched above.
>
> > Here is a scratch file on which I did some experiment commented.
> Fine exercise. Appreciated!
>
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t)))
> yield (to find out whether these 10/8 are due to the decorations)?
>
" LEFT=0 TOP=(+ -30)"
;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with <open> and enter text in its buffer.
;; Experiments with set-frame-position and the result values of the parameters left and top of the frame
;; Each parenthesis sexp has been evaluated with C-j = eval-print-last-sexp
(defun pl-lt ()
"Returns a string giving the left/top positions of the current frame"
(concat " LEFT="
(prin1-to-string (frame-parameter nil 'left))
" TOP="
(prin1-to-string (frame-parameter nil 'top))))
;; 4eme experience 2 displays: on left: internal screen=2ndary display , on right: external=primary display with dock and menu on right
;; the frame is located in the internal screen
(display-monitor-attributes-list)
(((name . "HDMI-1") (geometry 1920 0 1920 1080) (workarea 1920 27 1920 1053) (mm-size 521 293) (frames) (source . "Gdk")) ((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 309 174) (frames #<frame *unsent mail to martin rudalics* 0x5289930> #<frame test-frame-set-position-Martin-1.el 0x624cc90>) (source . "Gdk")))
(set-frame-position nil 0 0)
t
(pl-lt)
" LEFT=(+ -10) TOP=(+ -8)"
(progn (set-frame-position nil 0 0) (pl-lt))
" LEFT=0 TOP=0"
(progn (set-frame-position nil 0 0) (sleep-for 5) (pl-lt))
" LEFT=(+ -10) TOP=(+ -8)"
(modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t)))
nil
(pl-lt)
" LEFT=0 TOP=(+ -30)"
(modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
nil
(pl-lt)
" LEFT=0 TOP=(+ -30)"
(modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0) (undecorated . nil)))
nil
(pl-lt)
" LEFT=(+ -10) TOP=(+ -8)"
===================================
Best,Pascal
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 18:38:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 38452 <at> debbugs.gnu.org (full text, mbox):
>> BTW, I still don't
>> know what your window manager is.
>
> I guess it is gdm3 as I entered the following commands:
That's a display manager.
>> If we say that the origin for things to display on screen is (-10, -8)
>> - something you could probably verify by moving the dock to the right
>> and the menu bar line to the bottom - we have a clue. Just that it
>> doesn't make sense to me, yet.
>
> Not sure: when I try with (undecorated.t) I get LEFT=0 TOP=(+ -30)
> So the left side seems to be at 0.
So it seems that your window manager skips the decorations when a
frame is adjacent to an edge by just moving that frame outside the
display by the size of the decoration. Some window managers make this
customizable IIRC.
> ;; 4eme experience 2 displays: on left: internal screen=2ndary display , on right: external=primary display with dock and menu on right
> ;; the frame is located in the internal screen
> (display-monitor-attributes-list)
> (((name . "HDMI-1") (geometry 1920 0 1920 1080) (workarea 1920 27 1920 1053) (mm-size 521 293) (frames) (source . "Gdk")) ((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 309 174) (frames #<frame *unsent mail to martin rudalics* 0x5289930> #<frame test-frame-set-position-Martin-1.el 0x624cc90>) (source . "Gdk")))
>
>
> (set-frame-position nil 0 0)
> t
> (pl-lt)
> " LEFT=(+ -10) TOP=(+ -8)"
>
> (progn (set-frame-position nil 0 0) (pl-lt))
> " LEFT=0 TOP=0"
>
> (progn (set-frame-position nil 0 0) (sleep-for 5) (pl-lt))
> " LEFT=(+ -10) TOP=(+ -8)"
>
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t)))
> nil
> (pl-lt)
> " LEFT=0 TOP=(+ -30)"
>
>
>
> (modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
> nil
> (pl-lt)
> " LEFT=0 TOP=(+ -30)"
But the interesting case is whether specifying 'user-position' would
have any impact when the dock and the menu bar line are present on the
same frame, that is, the single display case.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Tue, 03 Dec 2019 18:54:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> >> BTW, I still don't
> >> know what your window manager is.
> >
> > I guess it is gdm3 as I entered the following commands:
>
> That's a display manager.
>
Hmmm I dont know how to et the information about the window manager.
I know that my linux is ubuntu 18 and I dont thing that I changed
anything arelated to the window manager from the standard configurtation.
Do you have some idea of how I could know what is my window manager ?
> >> If we say that the origin for things to display on screen is (-10, -8)
> >> - something you could probably verify by moving the dock to the right
> >> and the menu bar line to the bottom - we have a clue. Just that it
> >> doesn't make sense to me, yet.
> >
> > Not sure: when I try with (undecorated.t) I get LEFT=0 TOP=(+ -30)
> > So the left side seems to be at 0.
>
> So it seems that your window manager skips the decorations when a
> frame is adjacent to an edge by just moving that frame outside the
> display by the size of the decoration. Some window managers make this
> customizable IIRC.
>
> > ;; 4eme experience 2 displays: on left: internal screen=2ndary display , on right: external=primary display with dock and menu on right
> > ;; the frame is located in the internal screen
> > (display-monitor-attributes-list)
> > (((name . "HDMI-1") (geometry 1920 0 1920 1080) (workarea 1920 27 1920 1053) (mm-size 521 293) (frames) (source . "Gdk")) ((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 309 174) (frames #<frame *unsent mail to martin rudalics* 0x5289930> #<frame test-frame-set-position-Martin-1.el 0x624cc90>) (source . "Gdk")))
> >
> >
> > (set-frame-position nil 0 0)
> > t
> > (pl-lt)
> > " LEFT=(+ -10) TOP=(+ -8)"
> >
> > (progn (set-frame-position nil 0 0) (pl-lt))
> > " LEFT=0 TOP=0"
> >
> > (progn (set-frame-position nil 0 0) (sleep-for 5) (pl-lt))
> > " LEFT=(+ -10) TOP=(+ -8)"
> >
> >
> > (modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t)))
> > nil
> > (pl-lt)
> > " LEFT=0 TOP=(+ -30)"
> >
> >
> >
> > (modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
> > nil
> > (pl-lt)
> > " LEFT=0 TOP=(+ -30)"
>
> But the interesting case is whether specifying 'user-position' would
> have any impact when the dock and the menu bar line are present on the
> same frame, that is, the single display case.
>
My new experiment with a single display, the dock at left and menu line
at top:
(display-monitor-attributes-list)
(((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053) (mm-size 309 174) (frames #<frame *notmuch-id:2b232b16-497e-22d8-a395-9fae6e87add7 <at> gmx.at* 0x5289930> #<frame test-frame-set-position-Martin-1.el 0x624cc90>) (source . "Gdk")))
(modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
nil
(pl-lt)
" LEFT=45 TOP=19"
> martin
Pascal
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Wed, 04 Dec 2019 09:21:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> Hmmm I dont know how to et the information about the window manager.
> I know that my linux is ubuntu 18 and I dont thing that I changed
> anything arelated to the window manager from the standard configurtation.
> Do you have some idea of how I could know what is my window manager ?
If you have it installed you could try wmctrl -m. If you have not
changed anything, the answer should be probably Mutter for the GNOME 3
desktop. Note that I'm asking for this information because I'm
considering to add an entry to Emacs' PROBLEMS section, sketching the
behavior you report. And I wonder that no one else has reported a
similar behavior so far. BTW are "dock" and "menu bar line" official
nomeclature on GNOME 3?
>> But the interesting case is whether specifying 'user-position' would
>> have any impact when the dock and the menu bar line are present on the
>> same frame, that is, the single display case.
"same frame" was silly, sorry.
> My new experiment with a single display, the dock at left and menu line
> at top:
>
> (display-monitor-attributes-list)
> (((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053) (mm-size 309 174) (frames #<frame *notmuch-id:2b232b16-497e-22d8-a395-9fae6e87add7 <at> gmx.at* 0x5289930> #<frame test-frame-set-position-Martin-1.el 0x624cc90>) (source . "Gdk")))
>
> (modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))
> nil
> (pl-lt)
> " LEFT=45 TOP=19"
So specifying 'user-position' doesn't get us anywhere. Could you send
us two screenshots of your display?
(1) One where an Emacs frame is positioned at the top left corner of a
display _without_ dock and menu bar line. I'd like to see whether
that frame's decorations are visibly moved to some position
outside the screen.
(2) One where the Emacs frame is positioned right in the middle of the
display.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Thu, 05 Dec 2019 09:07:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> M-! wmctrl -m ==>
> Name: GNOME Shell
> Class: N/A
> PID: N/A
> Window manager's "showing the desktop" mode: N/A
OK. Let's stick to "GNOME Shell" then.
> I attach the two print screen.
Thanks. All I can derive from these shots is that GNOME doesn't draw
any borders around a window. What does evaluating (x-frame-geometry)
yield for such a frame?
> For (1) I put the dock on the right side but I do not know how to remove
> the topbar :-(
Given the fact that it's called topbar it maybe even can't be moved to
the bottom of the screen.
I'm slowly coming to the conclusion that Emacs doesn't do its
calculations right for GNOME windows. Maybe it should try to rely
more on EWMHs instead of using XCB. Unfortunately, the person who
wrote the code has left us and people knowing much about using size
hints and going up window hierarchies are rare.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Fri, 06 Dec 2019 09:13:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 38452 <at> debbugs.gnu.org (full text, mbox):
Hi Martin,
> > M-! wmctrl -m ==>
> > Name: GNOME Shell
> > Class: N/A
> > PID: N/A
> > Window manager's "showing the desktop" mode: N/A
>
> OK. Let's stick to "GNOME Shell" then.
>
> > I attach the two print screen.
>
> Thanks. All I can derive from these shots is that GNOME doesn't draw
> any borders around a window.
>What does evaluating (x-frame-geometry) yield for such a frame?
The value of x-frame geometry depends on the dock position:
; if I set the dock at left:
(set-frame-position nil 0 0)
t
(setq pl-x-frame-geometry-dock-at-left (x-frame-geometry))
((outer-position 45 . 19) (outer-size 772 . 766) (external-border-size 10 . 10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 752 . 46) (internal-border-width . 0))
;if I set the dock at bottom:
(set-frame-position nil 0 0)
t
(setq pl-x-frame-geometry-dock-at-bottom (x-frame-geometry))
((outer-position -10 . 19) (outer-size 772 . 766) (external-border-size 10 . 10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 752 . 46) (internal-border-width . 0))
>
> > For (1) I put the dock on the right side but I do not know how to remove
> > the topbar :-(
>
> Given the fact that it's called topbar it maybe even can't be moved to
> the bottom of the screen.
>
> I'm slowly coming to the conclusion that Emacs doesn't do its
> calculations right for GNOME windows. Maybe it should try to rely
> more on EWMHs instead of using XCB. Unfortunately, the person who
> wrote the code has left us and people knowing much about using size
> hints and going up window hierarchies are rare.
>
> martin
Pascal
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Sun, 08 Dec 2019 02:34:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Thanks. Apparently GNOME draws a virtual 10 pixels wide border around
> each frame which is not visible but affects the value of frame
> position. Concludingly, we have two problems:
>
> (1) GNOME by no means allows to programmatically position a window
> within the screen estates used by the "dock" and the "top bar". I
> suppose that when you manually drag such a window with the mouse,
> it may move into these estates but will be hidden by the dock and
> the top bar.
I can move the frame manually under the left dock.
But I cannot move it manually under the topbar (or dont know how).
Another weird suprise:
- if I manually move the frame with some part under the dock and then
(set-frame-position nil 0 0)
the frame jump at the leftmost position of the screen (partly covered by the
dock) but still below the topbar.
Then the frame parametres return values:
" LEFT=(+ -10) TOP=19"
- if I move manually the frame in the middle of the screen, away from
the dock, and then
(set-frame-position nil 0 0)
the frame jumps just right to the dock, so not at the same position as
in the first case.
Then the frame parametres return values:
" LEFT=45 TOP=19"
So it seems possible to move the frame programatically under the dock
when it is alreasy under the dock.
A last point which confirms that the dock may have some role: if I move
manually a frame to try to put it under the dock, it first resists to
pass the dock and when you insist finally it passes under.
> As a last resort: Does it help when you set the
> frame's z-group parameter to 'above' like in
>
> (modify-frame-parameters nil '((z-group . above) (left . 0) (top . 0)))
No, it changes nothing to the horizontal position of the frame.
>
> (2) Frame positions are reported off by 10 and 8 pixels. While the
> value of 10 can be explained with the reported border width, the
> value 8 is yet unexplained.
>
> I think (1) can and should be documented in the Elisp manual. (2)
> might be a bug in Emacs but I don't know how to fix it.
>
> martin
Pascal
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Sun, 08 Dec 2019 03:27:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> The value of x-frame geometry depends on the dock position:
> ; if I set the dock at left:
> (set-frame-position nil 0 0)
> t
> (setq pl-x-frame-geometry-dock-at-left (x-frame-geometry))
> ((outer-position 45 . 19) (outer-size 772 . 766) (external-border-size 10 . 10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 752 . 46) (internal-border-width . 0))
>
> ;if I set the dock at bottom:
> (set-frame-position nil 0 0)
> t
> (setq pl-x-frame-geometry-dock-at-bottom (x-frame-geometry))
> ((outer-position -10 . 19) (outer-size 772 . 766) (external-border-size 10 . 10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 752 . 46) (internal-border-width . 0))
Thanks. Apparently GNOME draws a virtual 10 pixels wide border around
each frame which is not visible but affects the value of frame
position. Concludingly, we have two problems:
(1) GNOME by no means allows to programmatically position a window
within the screen estates used by the "dock" and the "top bar". I
suppose that when you manually drag such a window with the mouse,
it may move into these estates but will be hidden by the dock and
the top bar. As a last resort: Does it help when you set the
frame's z-group parameter to 'above' like in
(modify-frame-parameters nil '((z-group . above) (left . 0) (top . 0)))
(2) Frame positions are reported off by 10 and 8 pixels. While the
value of 10 can be explained with the reported border width, the
value 8 is yet unexplained.
I think (1) can and should be documented in the Elisp manual. (2)
might be a bug in Emacs but I don't know how to fix it.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Sun, 08 Dec 2019 08:59:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> Another weird suprise:
> - if I manually move the frame with some part under the dock and then
> (set-frame-position nil 0 0)
> the frame jump at the leftmost position of the screen (partly covered by the
> dock) but still below the topbar.
> Then the frame parametres return values:
> " LEFT=(+ -10) TOP=19"
Interesting but hardly usable for programmed positioning.
> - if I move manually the frame in the middle of the screen, away from
> the dock, and then
> (set-frame-position nil 0 0)
> the frame jumps just right to the dock, so not at the same position as
> in the first case.
> Then the frame parametres return values:
> " LEFT=45 TOP=19"
>
> So it seems possible to move the frame programatically under the dock
> when it is alreasy under the dock.
>
> A last point which confirms that the dock may have some role: if I move
> manually a frame to try to put it under the dock, it first resists to
> pass the dock and when you insist finally it passes under.
You have to move the mouse beyond a threshold of a few pixels before
it continues moving.
>> As a last resort: Does it help when you set the
>> frame's z-group parameter to 'above' like in
>>
>> (modify-frame-parameters nil '((z-group . above) (left . 0) (top . 0)))
> No, it changes nothing to the horizontal position of the frame.
Does it at least have the Emacs frame appear on top of the dock?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Sun, 08 Dec 2019 10:03:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> >> As a last resort: Does it help when you set the
> >> frame's z-group parameter to 'above' like in
> >>
> >> (modify-frame-parameters nil '((z-group . above) (left . 0) (top . 0)))
> > No, it changes nothing to the horizontal position of the frame.
>
> Does it at least have the Emacs frame appear on top of the dock?
No, if I move manually towards the dock the frame with (z-group
. above) it appears under the dock (the dock is half transparent).
Note that the frame can manually be moved very much to the left of the
left side, with part of the frame disappearing out of the screen.
>
> martin
Pascal
--
Pascal Lambrechts -- UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161
IRMP bte L7.01.02 // Chemin du Cyclotron 2 // 1348 Louvain-la-Neuve // Belgium
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Mon, 09 Dec 2019 09:21:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 38452 <at> debbugs.gnu.org (full text, mbox):
>> Does it at least have the Emacs frame appear on top of the dock?
> No, if I move manually towards the dock the frame with (z-group
> . above) it appears under the dock (the dock is half transparent).
So it looks like Emacs doesn't have much power on your system. Would
working with wmctrl give you more power? You should be able to get
the position and size of an Emacs window with the -G argument and move
it via the -e argument, see for example
https://manpages.ubuntu.com/manpages/trusty/en/man1/wmctrl.1.html
> Note that the frame can manually be moved very much to the left of the
> left side, with part of the frame disappearing out of the screen.
That's normal.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Wed, 13 Apr 2022 02:02:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> No, if I move manually towards the dock the frame with (z-group
>> . above) it appears under the dock (the dock is half transparent).
>
> So it looks like Emacs doesn't have much power on your system. Would
> working with wmctrl give you more power? You should be able to get
> the position and size of an Emacs window with the -G argument and move
> it via the -e argument, see for example
>
> https://manpages.ubuntu.com/manpages/trusty/en/man1/wmctrl.1.html
Skimming this bug report, it seems like there's nothing to be done here
on the Emacs side, because this is all a window manager issue? Is that
accurate?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 13 Apr 2022 02:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Wed, 13 Apr 2022 08:46:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 38452 <at> debbugs.gnu.org (full text, mbox):
> Skimming this bug report, it seems like there's nothing to be done here
> on the Emacs side, because this is all a window manager issue? Is that
> accurate?
I suppose so. GNOME shell users should be able to change some aspects
in their dconf settings (in particular those regarding the size of the
invisible borders around frames that trigger those confusing frame
positions) but I never tried them so I can't really tell.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#38452; Package
emacs.
(Wed, 13 Apr 2022 11:56:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 38452 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Skimming this bug report, it seems like there's nothing to be done here
>> on the Emacs side, because this is all a window manager issue? Is that
>> accurate?
>
> I suppose so. GNOME shell users should be able to change some aspects
> in their dconf settings (in particular those regarding the size of the
> invisible borders around frames that trigger those confusing frame
> positions) but I never tried them so I can't really tell.
OK; closing this bug report, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
38452 <at> debbugs.gnu.org and Pascal Lambrechts <pascal.lambrechts <at> uclouvain.be>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 13 Apr 2022 11:56:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 12 May 2022 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 342 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.