GNU bug report logs - #76190
31.0.50; Setting frame parameter 'left (- -N) broken

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Tue, 11 Feb 2025 02:05:01 UTC

Severity: normal

Found in version 31.0.50

To reply to this bug, email your comments to 76190 AT debbugs.gnu.org.

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#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):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Tue, 11 Feb 2025 03:05:15 +0100
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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Po Lu <luangruo <at> yahoo.com>,
 martin rudalics <rudalics <at> gmx.at>
Cc: 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Tue, 11 Feb 2025 14:50:24 +0200
> 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):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Michael Heerdegen
 <michael_heerdegen <at> web.de>, Po Lu <luangruo <at> yahoo.com>
Cc: 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Tue, 11 Feb 2025 16:38:39 +0100
[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):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Po Lu <luangruo <at> yahoo.com>, martin rudalics <rudalics <at> gmx.at>,
 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 00:50:03 +0100
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):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>,
 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 00:54:25 +0100
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):

From: Po Lu <luangruo <at> yahoo.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 09:35:57 +0800
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):

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>,
 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 11:03:17 +0100
> 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):

From: martin rudalics <rudalics <at> gmx.at>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 76190 <at> debbugs.gnu.org
Subject: Re: bug#76190: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 11:03:56 +0100
> 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):

From: Angelo Graziosi <angelo.g0 <at> libero.it>
To: 76190 <at> debbugs.gnu.org
Subject: Re: 31.0.50; Setting frame parameter 'left (- -N) broken
Date: Wed, 12 Feb 2025 20:47:49 +0100
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.