bug#48202: 27.2; wrong frame position

bug#48202: 27.2; wrong frame position

[ynyaaa]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]


When evaluating (set-frame-position nil 0 0), emacs frame moves to
top-left of the screen, but there is a gap between the left edge of the
screen and the emacs frame.
The displayed position of 'emacs -g +0+0' is same as the above.

The attached image is the result of the commands below.
    runemacs -Q -D -T emacs --geometry +0+0
    runemacs -Q -D -T emacs --geometry -0+0
    runemacs -Q -D -T emacs --geometry +0-0
    runemacs -Q -D -T emacs --geometry -0-0


[-- Attachment #2: emacs at corners --]
[-- Type: image/png, Size: 25063 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2791 bytes --]




In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.964)

Recent messages:

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932

Major mode: Lisp Interaction

Minor modes in effect:
  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:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv 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
term/bobcat japan-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 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 w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 50308 6218)
 (symbols 48 6089 1)
 (strings 32 16917 2024)
 (string-bytes 1 524586)
 (vectors 16 11453)
 (vector-slots 8 213678 9010)
 (floats 8 21 295)
 (intervals 56 226 0)
 (buffers 1000 11))

bug#48202: 27.2; wrong frame position

[Eli Zaretskii]

> From: ynyaaa@gmail.com
> Date: Tue, 04 May 2021 02:58:32 +0900
> 
> When evaluating (set-frame-position nil 0 0), emacs frame moves to
> top-left of the screen, but there is a gap between the left edge of the
> screen and the emacs frame.

Maybe on Windows 10.  Here on XP I see no gap at all.

bug#48202: 27.2; wrong frame position

[martin rudalics]

 > When evaluating (set-frame-position nil 0 0), emacs frame moves to
 > top-left of the screen, but there is a gap between the left edge of the
 > screen and the emacs frame.
 > The displayed position of 'emacs -g +0+0' is same as the above.
 >
 > The attached image is the result of the commands below.
 >      runemacs -Q -D -T emacs --geometry +0+0
 >      runemacs -Q -D -T emacs --geometry -0+0
 >      runemacs -Q -D -T emacs --geometry +0-0
 >      runemacs -Q -D -T emacs --geometry -0-0
 >
 >
 >
 >
 >
 > In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 >   of 2021-03-26 built on CIRROCUMULUS
 > Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
 > Repository branch: HEAD
 > Windowing system distributor 'Microsoft Corp.', version 10.0.19042
 > System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.964)

I suppose it's those invisible borders which leave an 8 or so pixels
wide gap.  It's highly annoying, especially when you want to display two
frames side-by-side and yet another reason not to use Windows 10.  IIRC
the Autohotkey people had some sort of fix for it but maybe I
misremember.  GNOME shell has a similar problem BTW.

martin

bug#48202: 27.2; wrong frame position

[Eli Zaretskii]

tags 48202 notabug
close 48202
thanks

> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 4 May 2021 10:08:09 +0200
> 
> I suppose it's those invisible borders which leave an 8 or so pixels
> wide gap.  It's highly annoying, especially when you want to display two
> frames side-by-side and yet another reason not to use Windows 10.

Indeed.  It turns out this is a Windows 10 "feature": the border of
the window used for resizing by mouse is by default invisible (it can
be made visible by changing your desktop theme).  The border is
invisible, but it still takes its space on screen, to allow mouse
resizing.  The details can be found here:

  https://stackoverflow.com/questions/60700133/windows-desktop-coordinate-system-is-off-for-certain-windows?fireglass_rsn=true

> IIRC the Autohotkey people had some sort of fix for it but maybe I
> misremember.

I don't think there should be a fix: this is how the platform behaves,
and intentionally so.

So I don't think this is a bug, and I'm closing this bug report.

> GNOME shell has a similar problem BTW.

Of course, they all copycat each other.

bug#48202: 27.2; wrong frame position

[martin rudalics]

 > So I don't think this is a bug, and I'm closing this bug report.
 >
 >> GNOME shell has a similar problem BTW.
 >
 > Of course, they all copycat each other.

I think I'm going to close a few more bug reports then.

martin