bug#58627: 29.0.50; `set-frame-position' doesn't set frame position correctly when it is called with negative X or Y

bug#58627: 29.0.50; `set-frame-position' doesn't set frame position correctly when it is called with negative X or Y

[Yuwei Tian]

The manual for the function `set-frame-position' says this:

"Negative parameter values position the right edge of the outer
frame by -X pixels left from the right edge of the screen (or the
parent frame's native rectangle) and the bottom edge by - Y pixels
up from the bottom edge of the screen (or the parent frame's native
rectangle)."

Tested with NS port Emacs 28.2 and 29.0.50 on macOS 12.6.

In Emacs 28, when using `set-frame-position' to set the position of
the child frame, when X or Y is a negative value, it correctly sets
the position of the child frame so that its right edge is X pixels
away from the right edge of its parent frame or its bottom edge is
Y pixels away from the bottom edge of its parent frame.

But in Emacs 29, when X or Y is negative, `set-frame-position` sets
the position of child frame's (0, 0) point -X pixels left or -Y pixels
up from its parent frame's (0, 0) point.

`set-frame-position' has inconsistent behavior in Emacs 28 and 29.


In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.6.0, NS
appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-10-19 built on
fishtai0-macmini.local
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs-plus@29/29.0.50/share/info/emacs
--prefix=/usr/local/Cellar/emacs-plus@29/29.0.50 --with-xml2
--with-gnutls --without-compress-install --without-dbus
--without-imagemagick --with-modules --with-rsvg --with-ns
--disable-ns-self-contained 'CFLAGS=-Os -w -pipe -march=nehalem
-mmacosx-version-min=12
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
-DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
'CPPFLAGS=-I/usr/local/opt/icu4c/include
-I/usr/local/opt/openssl@1.1/include -I/usr/local/opt/readline/include
-F/usr/local/Frameworks
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
'LDFLAGS=-L/usr/local/opt/icu4c/lib -L/usr/local/opt/openssl@1.1/lib
-L/usr/local/opt/readline/lib -L/usr/local/lib -F/usr/local/Frameworks
-Wl,-headerpad_max_install_names
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 38723 7803)
(symbols 48 5013 0)
(strings 32 13162 1904)
(string-bytes 1 380714)
(vectors 16 10573)
(vector-slots 8 162118 16691)
(floats 8 21 18)
(intervals 56 378 0)
(buffers 1000 12))

bug#58627: 29.0.50; `set-frame-position' doesn't set frame position correctly when it is called with negative X or Y

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yuwei Tian <fishtai0@gmail.com> writes:

> The manual for the function `set-frame-position' says this:
>
> "Negative parameter values position the right edge of the outer
> frame by -X pixels left from the right edge of the screen (or the
> parent frame's native rectangle) and the bottom edge by - Y pixels
> up from the bottom edge of the screen (or the parent frame's native
> rectangle)."
>
> Tested with NS port Emacs 28.2 and 29.0.50 on macOS 12.6.
>
> In Emacs 28, when using `set-frame-position' to set the position of
> the child frame, when X or Y is a negative value, it correctly sets
> the position of the child frame so that its right edge is X pixels
> away from the right edge of its parent frame or its bottom edge is
> Y pixels away from the bottom edge of its parent frame.
>
> But in Emacs 29, when X or Y is negative, `set-frame-position` sets
> the position of child frame's (0, 0) point -X pixels left or -Y pixels
> up from its parent frame's (0, 0) point.
>
> `set-frame-position' has inconsistent behavior in Emacs 28 and 29.

Did you build Emacs 28.2 on Mac OS 12.6 as well?

bug#58627: 29.0.50; `set-frame-position' doesn't set frame position correctly when it is called with negative X or Y

[Yuwei Tian]

Sorry. I just built Emacs 28.2 on macOS 12.6. It behaves the same as Emacs 29.
I tested it again on the Mac port version of Emacs 28.2, and the behavior is the
same as described in the manual. Is it an issue with the NS version Emacs only?

On Wed, Oct 19, 2022 at 7:18 PM Po Lu <luangruo@yahoo.com> wrote:
>
> Yuwei Tian <fishtai0@gmail.com> writes:
>
> > The manual for the function `set-frame-position' says this:
> >
> > "Negative parameter values position the right edge of the outer
> > frame by -X pixels left from the right edge of the screen (or the
> > parent frame's native rectangle) and the bottom edge by - Y pixels
> > up from the bottom edge of the screen (or the parent frame's native
> > rectangle)."
> >
> > Tested with NS port Emacs 28.2 and 29.0.50 on macOS 12.6.
> >
> > In Emacs 28, when using `set-frame-position' to set the position of
> > the child frame, when X or Y is a negative value, it correctly sets
> > the position of the child frame so that its right edge is X pixels
> > away from the right edge of its parent frame or its bottom edge is
> > Y pixels away from the bottom edge of its parent frame.
> >
> > But in Emacs 29, when X or Y is negative, `set-frame-position` sets
> > the position of child frame's (0, 0) point -X pixels left or -Y pixels
> > up from its parent frame's (0, 0) point.
> >
> > `set-frame-position' has inconsistent behavior in Emacs 28 and 29.
>
> Did you build Emacs 28.2 on Mac OS 12.6 as well?

bug#58627: 29.0.50; `set-frame-position' doesn't set frame position correctly when it is called with negative X or Y

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Yuwei Tian <fishtai0@gmail.com> writes:

> Sorry. I just built Emacs 28.2 on macOS 12.6. It behaves the same as Emacs 29.
> I tested it again on the Mac port version of Emacs 28.2, and the behavior is the
> same as described in the manual. Is it an issue with the NS version Emacs only?

Carbon Emacs (the "Mac port") probably implements set-frame-position
correctly.  The NS port is definitely wrong there.

If someone points me to how Carbon Emacs implements it, I'd be happy to
implement it similarly for NS, as long as it doesn't use Carbon to move
the frame.