GNU bug report logs -
#76190
31.0.50; Setting frame parameter 'left (- -N) broken
Previous Next
To reply to this bug, email your comments to 76190 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Tue, 11 Feb 2025 02:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 11 Feb 2025 02:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
according to (info "(elisp) Position Parameters"),
(set-frame-parameter nil 'left '(- -100))
should move the selected frame to the right so a small part (100 pixels)
is moved outside of the current screen, and the rest is visible on the
right side. However, for me the effect is exactly the same as with
(set-frame-parameter nil 'left +100). A totally different result! I'm
quite sure that this worked for me as described a while ago. Something
has changed. I did not change my system setup AFAICT, still Openbox on
X, same monitor setup, same Notebook, same OS.
Other values do work as described. In particular do (+ -N) and
(+ +N) work as described (the latter case is similar to the broken one
but works for me).
Can others reproduce this?
TIA,
Michael.
In GNU Emacs 31.0.50 (build 42, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2025-02-11 built on drachen
Repository revision: d958a29bfbf0e7485e4b80f94d149d50d27edb89
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --with-x-toolkit=no --with-native-compilation=no'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR ZLIB
Important settings:
value of $LC_ALL: de_DE.utf8
value of $LC_COLLATE: C
value of $LC_TIME: C
value of $LANG: de_DE.utf8
locale-coding-system: utf-8-unix
Major mode: ELisp/l
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Tue, 11 Feb 2025 12:51:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76190 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 11 Feb 2025 03:05:15 +0100
> From: Michael Heerdegen via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> according to (info "(elisp) Position Parameters"),
>
> (set-frame-parameter nil 'left '(- -100))
>
> should move the selected frame to the right so a small part (100 pixels)
> is moved outside of the current screen, and the rest is visible on the
> right side. However, for me the effect is exactly the same as with
> (set-frame-parameter nil 'left +100). A totally different result! I'm
> quite sure that this worked for me as described a while ago. Something
> has changed. I did not change my system setup AFAICT, still Openbox on
> X, same monitor setup, same Notebook, same OS.
>
> Other values do work as described. In particular do (+ -N) and
> (+ +N) work as described (the latter case is similar to the broken one
> but works for me).
>
> Can others reproduce this?
I can't (on MS-Windows): the original example works for me as you
expected.
Maybe this is a problem with the non-toolkit build or something?
Po Lu and Martin, can you help?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Tue, 11 Feb 2025 15:39:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76190 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> according to (info "(elisp) Position Parameters"),
>>
>> (set-frame-parameter nil 'left '(- -100))
>>
>> should move the selected frame to the right so a small part (100 pixels)
>> is moved outside of the current screen, and the rest is visible on the
>> right side. However, for me the effect is exactly the same as with
>> (set-frame-parameter nil 'left +100). A totally different result! I'm
>> quite sure that this worked for me as described a while ago. Something
>> has changed. I did not change my system setup AFAICT, still Openbox on
>> X, same monitor setup, same Notebook, same OS.
>>
>> Other values do work as described. In particular do (+ -N) and
>> (+ +N) work as described (the latter case is similar to the broken one
>> but works for me).
>>
>> Can others reproduce this?
>
> I can't (on MS-Windows): the original example works for me as you
> expected.
I attached a patch. Can you try it Michael?
martin
[xterm.c.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Tue, 11 Feb 2025 23:49:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76190 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Maybe this is a problem with the non-toolkit build or something?
I indeed had switched to the non-toolkit build some months ago.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Tue, 11 Feb 2025 23:54:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76190 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I attached a patch. Can you try it Michael?
Sure.
Yes, the patch indeed fixes the problem for me. With the patch all
combinations +N, -N, (- +N) and (- -N) work as described with my build.
Thank you!
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Wed, 12 Feb 2025 01:37:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 76190 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> according to (info "(elisp) Position Parameters"),
>>>
>>> (set-frame-parameter nil 'left '(- -100))
>>>
>>> should move the selected frame to the right so a small part (100 pixels)
>>> is moved outside of the current screen, and the rest is visible on the
>>> right side. However, for me the effect is exactly the same as with
>>> (set-frame-parameter nil 'left +100). A totally different result! I'm
>>> quite sure that this worked for me as described a while ago. Something
>>> has changed. I did not change my system setup AFAICT, still Openbox on
>>> X, same monitor setup, same Notebook, same OS.
>>>
>>> Other values do work as described. In particular do (+ -N) and
>>> (+ +N) work as described (the latter case is similar to the broken one
>>> but works for me).
>>>
>>> Can others reproduce this?
>>
>> I can't (on MS-Windows): the original example works for me as you
>> expected.
>
> I attached a patch. Can you try it Michael?
>
> martin
>
> diff --git a/src/xterm.c b/src/xterm.c
> index 0a877e9edf9..962166f3d3e 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -27512,7 +27512,7 @@ x_calc_absolute_position (struct frame *f)
>
> /* Treat negative positions as relative to the leftmost bottommost
> position that fits on the screen. */
> - if ((flags & XNegative) && (f->left_pos <= 0))
> + if (flags & XNegative)
> {
> int width = FRAME_PIXEL_WIDTH (f);
>
> @@ -27539,7 +27539,7 @@ x_calc_absolute_position (struct frame *f)
>
> }
>
> - if ((flags & YNegative) && (f->top_pos <= 0))
> + if (flags & YNegative)
> {
> int height = FRAME_PIXEL_HEIGHT (f);
>
This and the documented behavior in the maual doesn't appear correct to
me, as XParseGeometry returns a negative value if XNegative is set.
Hence f->left_pos is meant always to be negative if (flags & XNegative),
and after all, "=100x100--100+0" is not a valid geometry string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Wed, 12 Feb 2025 10:04:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 76190 <at> debbugs.gnu.org (full text, mbox):
> Yes, the patch indeed fixes the problem for me. With the patch all
> combinations +N, -N, (- +N) and (- -N) work as described with my build.
I pushed it now. Let's see if it breaks anything.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Wed, 12 Feb 2025 10:05:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 76190 <at> debbugs.gnu.org (full text, mbox):
> This and the documented behavior in the maual doesn't appear correct to
> me, as XParseGeometry returns a negative value if XNegative is set.
> Hence f->left_pos is meant always to be negative if (flags & XNegative),
> and after all, "=100x100--100+0" is not a valid geometry string.
Can you propose a fix? IIUC XParseGeometry doesn't support positioning
the top of a frame at negative coordinates anyway.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76190
; Package
emacs
.
(Wed, 12 Feb 2025 19:48:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 76190 <at> debbugs.gnu.org (full text, mbox):
I had noticed this issue some time ago. It shows up only on GNU/Linux
(Mint, here). For example, to have the top right corner of Emacs aligned
with the top right corner of the Desktop, I have to put on Windows:
(left . (- -5)) ; pixel
(top . 0) ; pixel
On GNU/Linux, instead I had
(left . 830) ; pixel
(top . 0) ; pixel
After your fix, On GNU/Linux I can put
(left . (- -20)) ; pixel
(top . 0) ; pixel
But with the same binaries installed, on WSL I have to put
(left . (- -60)) ; pixel
(top . 0) ; pixel
May you explain why this difference?
Why, in any case (also on Windows), I have to do a negative shift?
Have you some suggestion to test to have TR corner on TR corner of the
Desktop?
TIA,
Angelo.
This bug report was last modified 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.