GNU bug report logs - #79443
30.2; Window frame not whole number of lines

Previous Next

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

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79351 <at> debbugs.gnu.org
Subject: 30.2; Window frame not whole number of lines
Date: Sat, 13 Sep 2025 15:09:56 +0300

[Message part 1 (text/plain, inline)]

X-Debbugs-Cc:
--text follows this line--




In GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
 cairo version 1.18.0) of 2025-08-17, modified by Debian built on
 lcy02-amd64-056
System Description: Ubuntu 24.04.2 LTS

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/libexec --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/30.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/30.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-pgtk
 'CFLAGS=-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
 -ffile-prefix-map=/build/emacs-LEe2cs/emacs-30.2=. -fstack-protector-strong
 -fstack-clash-protection -Wformat -Werror=format-security
 -fcf-protection
 -fdebug-prefix-map=/build/emacs-LEe2cs/emacs-30.2=/usr/src/emacs-1:30.2-0build1~ubuntu2404
 -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=3'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  windmove-mode: t
  checkdoc-minor-mode: t
  smart-newline-mode: t
  snap-indent-mode: t
  highlight-indent-guides-mode: t
  highlight-symbol-mode: t
  flycheck-mode: t
  visual-wrap-prefix-mode: t
  outline-minor-mode: t
  hl-line-mode: t
  display-line-numbers-mode: t
  save-place-mode: t
  xterm-mouse-mode: t
  winner-mode: t
  which-key-mode: t
  which-function-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-global-mode: t
  smartparens-mode: t
  savehist-mode: t
  recentf-mode: t
  popper-mode: t
  keyfreq-autosave-mode: t
  keyfreq-mode: t
  helm-adaptive-mode: t
  global-git-gutter+-mode: t
  git-gutter+-mode: t
  global-git-commit-mode: t
  server-mode: t
  global-anzu-mode: t
  anzu-mode: t
  volatile-highlights-mode: t
  drag-stuff-global-mode: t
  drag-stuff-mode: t
  counsel-projectile-mode: t
  counsel-mode: t
  ivy-mode: t
  delete-selection-mode: t
  projectile-mode: t
  yas-minor-mode: t
  textmate-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  inertias-global-minor-mode: t
  tooltip-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: #[128 \304\300\301 #\207 [yas--auto-fill
do-auto-fill :around nil apply] 5 advice]
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  hs-minor-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm hides
/usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-autoloads hides
/usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-autoloads
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-pkg hides
/usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-pkg
/usr/share/emacs/site-lisp/elpa/vterm-0.0.2/vterm-load-path hides
/usr/share/emacs/site-lisp/elpa-src/vterm-0.0.2/vterm-load-path
/home/netsu/.emacs.d/el-get/transient/lisp/transient hides
/usr/share/emacs/30.2/lisp/transient
/home/netsu/.emacs.d/el-get/peg/peg hides
/usr/share/emacs/30.2/lisp/progmodes/peg
/home/netsu/.emacs.d/el-get/compat/compat hides
/usr/share/emacs/30.2/lisp/emacs-lisp/compat

Features:
(shadow sort mail-extr help-fns cl-print debug backtrace windmove
emacsbug nix-sandbox s vc-git diff-mode track-changes vc-dispatcher
checkdoc smart-newline snap-indent highlight-indent-guides
highlight-symbol flycheck visual-wrap noutline outline hideshow hl-line
display-line-numbers ffap disp-table done keybindings vcursor misc
cap-words superword subword saveplace myrth-theme xt-mouse winner
which-key which-func smartparens-config smartparens-text smartparens
loadhist savehist recentf tree-widget popper keyfreq helm-adaptive
git-gutter-fringe+ fringe-helper git-gutter+ git-commit magit-process
with-editor server magit-mode transient benchmark magit-git magit-base
magit-section cursor-sensor crm llama compat compat-30 log-edit message
sendmail yank-media rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mailabbrev mail-utils
gmm-utils mailheader pcvs-util add-log dash anzu cua-base hooks hacks
plugins getelget slim-mode ein skewer-setup ocp-indent
haskell-mode-autoloads diminish dired+ image-file image-converter
dired-x dired-aux srep comp comp-cstr comp-run comp-common etags
fileloop generator volatile-highlights drag-stuff fastnav
counsel-projectile counsel xref swiper ivy flx delsel ivy-faces
ivy-overlay colir color projectile grep ibuf-ext ibuffer
ibuffer-loaddefs goto-last-change company pcase smex helm-c-yasnippet
clojure-snippets yasnippet flymake project compile text-property-search
warnings thingatpt ido textmate imenu monky view ediff ediff-merg
ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util bindat
helm-descbinds helm-mode helm-misc helm-files image-dired
image-dired-tags image-dired-external image-dired-util image-mode exif
filenotify tramp trampver tramp-integration files-x tramp-message
tramp-compat xdg shell pcomplete comint ansi-osc parse-time iso8601
time-date tramp-loaddefs helm-buffers helm-x-icons helm-occur helm-tags
helm-locate helm-grep helm-regexp format-spec ansi-color helm-utils
helm-help helm-types helm helm-global-bindings helm-easymenu helm-core
easy-mmode helm-source helm-multi-match helm-lib async helm-autoloads
undo-tree diff queue jquery-doc xml jquery-doc-data find-func
auto-complete-config auto-complete popup avy ring inertial-scroll
edmacro kmacro deferred cl advice rx el-get el-get-autoloading
el-get-list-packages el-get-dependencies el-get-build el-get-status
el-get-methods el-get-fossil el-get-svn el-get-pacman el-get-github-zip
el-get-github-tar el-get-http-zip el-get-http-tar el-get-hg el-get-go
el-get-git-svn el-get-fink el-get-emacswiki el-get-http el-get-notify
el-get-emacsmirror el-get-github el-get-git url-http url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm puny
el-get-elpa el-get-darcs el-get-cvs el-get-bzr el-get-brew
el-get-builtin el-get-apt-get el-get-recipes el-get-byte-compile
el-get-custom cl-extra help-mode el-get-core autoload loaddefs-gen
radix-tree lisp-mnt dired dired-loaddefs finder-inf cus-edit pp cus-load
wid-edit queue-autoloads rainbow-mode-autoloads vterm-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs icons
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd 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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 665960 155175) (symbols 48 39471 1) (strings 32 139296 10403)
 (string-bytes 1 5104136) (vectors 16 83444) (vector-slots 8 1646571 80364)
 (floats 8 438 382) (intervals 56 10522 290) (buffers 992 14))


Hello!

When I open a new, in opens with not a whole line numbers, despite
window-resize-pixelwise nil,
pixel-scroll-precision-mode nil.
When resizing with mouse, the frame size changes line-by-line, but
there's still not a whole amount of the visible lines remaining.

Desired behavior: UX must be exactly the same as in TTY.

Please, feel free to ask any additional details according to this report.

M-: (window--dump-frame)

frame pixel: 909 x 1003   cols/lines: 101 x 47   units: 9 x 21
frame text pixel: 893 x 1003   cols/lines: 99 x 47
tab: 0  tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on custom.el>   parent: nil
pixel left: 0   top: 0   size: 909 x 982   new: 751
char left: 0   top: 0   size: 101 x 46   new: 36
normal: 1.0 x 1.0   new: nil
body pixel: 893 x 961   char: 99 x 45
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 21
height scroll-bar: 0 divider: 0
#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 982   size: 909 x 21   new: 252
char left: 0   top: 46   size: 101 x 1   new: 12
normal: 1.0 x 1.0   new: 0
body pixel: 893 x 21   char: 99 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 0
height scroll-bar: 0 divider: 0

After resize:

frame pixel: 612 x 205   cols/lines: 68 x 9   units: 9 x 21
frame text pixel: 596 x 205   cols/lines: 66 x 9
tab: 0  tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *unsent mail to bug-gnu-emacs <at> gnu.org*>   parent: nil
pixel left: 0   top: 0   size: 612 x 184   new: 184
char left: 0   top: 0   size: 68 x 9   new: 9
normal: 1.0 x 1.0   new: 1.0
body pixel: 596 x 163   char: 66 x 7
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 21
height scroll-bar: 0 divider: 0
#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 184   size: 612 x 21   new: 37
char left: 0   top: 9   size: 68 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 596 x 21   char: 66 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 0
height scroll-bar: 0 divider: 0

--

frame pixel: 522 x 205   cols/lines: 58 x 9   units: 9 x 21
frame text pixel: 506 x 205   cols/lines: 56 x 9
tab: 0  tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 10>   parent: nil
pixel left: 0   top: 0   size: 522 x 184   new: 168
char left: 0   top: 0   size: 58 x 9   new: 9
normal: 1.0 x 1.0   new: nil

#<window 3 on *window-frame-dump*>   parent: #<window 10>
pixel left: 0   top: 0   size: 522 x 100   new: 84
char left: 0   top: 0   size: 58 x 5   new: 4
normal: 1.0 x 0.5   new: skip
body pixel: 506 x 79   char: 56 x 3
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 21
height scroll-bar: 0 divider: 0
#<window 11 on *window-frame-dump*>   parent: #<window 10>
pixel left: 0   top: 100   size: 522 x 84   new: 84
char left: 0   top: 5   size: 58 x 4   new: 4
normal: 1.0 x 0.5   new: nil
body pixel: 506 x 63   char: 56 x 3
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 21
height scroll-bar: 0 divider: 0
#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 184   size: 522 x 21   new: 37
char left: 0   top: 9   size: 58 x 1   new: 2
normal: 1.0 x 1.0   new: 0
body pixel: 506 x 21   char: 56 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height tab-line: 0 header-line: 0  mode-line: 0
height scroll-bar: 0 divider: 0


OS: Ubuntu 24.04 (no modifications, default)

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.2 LTS
Release:        24.04
Codename:       noble


-- 
With best regards,
Yurii Pytomets

[image.png (image/png, attachment)]

[image.png (image/png, attachment)]

[image.png (image/png, attachment)]

Message #8 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>, 79443 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Sun, 14 Sep 2025 11:22:53 +0200

> M-: (window--dump-frame)
>
> frame pixel: 909 x 1003   cols/lines: 101 x 47   units: 9 x 21
> frame text pixel: 893 x 1003   cols/lines: 99 x 47
> tab: 0  tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

The problem is here since

99 * 9 ~> 891
47 * 21 ~> 987

and

> After resize:
>
> frame pixel: 612 x 205   cols/lines: 68 x 9   units: 9 x 21
> frame text pixel: 596 x 205   cols/lines: 66 x 9
> tab: 0  tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

66 * 9 ~> 594
9 * 21 ~> 189

So your reported frame text width is constantly larger than the expected
one by 2 pixels (893 - 891, 596 - 594) and the reported frame text
height is constantly larger than the expected one by 16 pixels (1003 -
987, 205 - 189).  Compare this to what I get for my GTK+ build here

frame pixel: 752 x 792   cols/lines: 83 x 36   units: 9 x 22
frame text pixel: 720 x 792   cols/lines: 80 x 36
tab: 0  tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

where 752 equals 80 * 9 + 16 + 16 and 792 equals 36 * 22..

The remainder of 16 pixels should truncate the last non-minibuffer line
by 5 pixels which seems to confirm what you observe.  Note that when the
minibuffer gets resized as in your last image the truncated line appears
there.  I can't tell whether the 2 additional pixels for the width are
visible too.

So far I can only guess what's causing these.  One observation is that
you turned off scroll bars.  This might explain the 2 pixels for the
width gap.  Maybe some other customization is responsible for the height
gap.  Please repeat the experiment with emacs -Q, this might gives us
more insight.

Thanks, martin

Message #11 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: 79443 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Thu, 18 Sep 2025 18:42:35 +0300

[Message part 1 (text/plain, inline)]

> emacs-pgtk -Q
> M-: (window--dump-frame)

frame pixel: 830 x 751   cols/lines: 83 x 35   units: 10 x 21
frame text pixel: 798 x 751   cols/lines: 79 x 35
tab: 0  tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *scratch*>   parent: nil
pixel left: 0   top: 0   size: 830 x 730   new: 0
char left: 0   top: 0   size: 83 x 34   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 798 x 709   char: 79 x 33
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height tab-line: 0 header-line: 0  mode-line: 21
height scroll-bar: 0 divider: 0
#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 730   size: 830 x 21   new: 0
char left: 0   top: 34   size: 83 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 798 x 21   char: 79 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height tab-line: 0 header-line: 0  mode-line: 0
height scroll-bar: 0 divider: 0


-- 
With best regards,
Yurii Pytomets

[Screenshot from 2025-09-18 18-41-07.png (image/png, attachment)]

Message #14 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: 79443 <at> debbugs.gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Thu, 18 Sep 2025 19:49:08 +0300

[Message part 1 (text/plain, inline)]

Notice: calling (toggle-frame-fullscreen) several times in row reducing the
frame size iteratively.

On Thu, Sep 18, 2025 at 6:42 PM Yurii Pytomets <pitometsu <at> gmail.com> wrote:

> > emacs-pgtk -Q
> > M-: (window--dump-frame)
>
> frame pixel: 830 x 751   cols/lines: 83 x 35   units: 10 x 21
> frame text pixel: 798 x 751   cols/lines: 79 x 35
> tab: 0  tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0
>
> #<window 3 on *scratch*>   parent: nil
> pixel left: 0   top: 0   size: 830 x 730   new: 0
> char left: 0   top: 0   size: 83 x 34   new: 0
> normal: 1.0 x 1.0   new: 0
> body pixel: 798 x 709   char: 79 x 33
> width left fringe: 8  left margin: 0  right margin: 0
> width right fringe: 8  scroll-bar: 16  divider: 0
> height tab-line: 0 header-line: 0  mode-line: 21
> height scroll-bar: 0 divider: 0
> #<window 4 on  *Minibuf-0*>   parent: nil
> pixel left: 0   top: 730   size: 830 x 21   new: 0
> char left: 0   top: 34   size: 83 x 1   new: 0
> normal: 1.0 x 1.0   new: 0
> body pixel: 798 x 21   char: 79 x 1
> width left fringe: 8  left margin: 0  right margin: 0
> width right fringe: 8  scroll-bar: 16  divider: 0
> height tab-line: 0 header-line: 0  mode-line: 0
> height scroll-bar: 0 divider: 0
>
>
> --
> With best regards,
> Yurii Pytomets
>

[Message part 2 (text/html, inline)]

Message #17 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>, 79443 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Fri, 19 Sep 2025 11:58:25 +0200

>> emacs-pgtk -Q

Same height gap of 16 pixels, the width gap changed to 8 pixels.

I only now realized that you are using a pgtk build and thus very likely
a Wayland backend.  If you _are_ using Wayland, you usually can forget
characterwise resizing of frames: Wayland officially does not support
size increment hints like X11 and there's no way to tell it to resize
frames in increments of character sizes only.  In fact, you should
probably set 'frame-resize-pixelwise' to t, this might help when
toggling fullscreen.

Though: I tried here with Plasma Wayland and it apparently does obey
size increments.  This might be a KWin peculiarity so if you are using
another desktop or WM your results will likely differ.  Which desktop/WM
do you use?

martin

Message #20 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Fri, 19 Sep 2025 13:08:23 +0300

So could there be a workaround for Wayland: e.g. correct margins
pixel-wise so that would compensate for a gap between the frame size
and an appropriate window size with the whole number of rows and
columns?

On Fri, Sep 19, 2025 at 12:58 PM martin rudalics <rudalics <at> gmx.at> wrote:
>
>  >> emacs-pgtk -Q
>
> Same height gap of 16 pixels, the width gap changed to 8 pixels.
>
> I only now realized that you are using a pgtk build and thus very likely
> a Wayland backend.  If you _are_ using Wayland, you usually can forget
> characterwise resizing of frames: Wayland officially does not support
> size increment hints like X11 and there's no way to tell it to resize
> frames in increments of character sizes only.  In fact, you should
> probably set 'frame-resize-pixelwise' to t, this might help when
> toggling fullscreen.
>
> Though: I tried here with Plasma Wayland and it apparently does obey
> size increments.  This might be a KWin peculiarity so if you are using
> another desktop or WM your results will likely differ.  Which desktop/WM
> do you use?
>
> martin



-- 
With best regards,
Yurii Pytomets

Message #23 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Fri, 19 Sep 2025 13:21:39 +0300

[Message part 1 (text/plain, inline)]

$ echo $XDG_CURRENT_DESKTOP
ubuntu:GNOME

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.2 LTS
Release:        24.04
Codename:       noble

With no essential customizations (just disabled some hotkeys so my emacs
shortcuts works).

Actually, that would be great to have a single character-wise option to
prohibit ANY pixel-wise behavior: that would be much more sustainable then
debug and catch each package that affect window creating/resizing/scrolling
and produce jumping-the-mess-around behavior.


On Fri, Sep 19, 2025 at 1:08 PM Yurii Pytomets <pitometsu <at> gmail.com> wrote:

> So could there be a workaround for Wayland: e.g. correct margins
> pixel-wise so that would compensate for a gap between the frame size
> and an appropriate window size with the whole number of rows and
> columns?
>
> On Fri, Sep 19, 2025 at 12:58 PM martin rudalics <rudalics <at> gmx.at> wrote:
> >
> >  >> emacs-pgtk -Q
> >
> > Same height gap of 16 pixels, the width gap changed to 8 pixels.
> >
> > I only now realized that you are using a pgtk build and thus very likely
> > a Wayland backend.  If you _are_ using Wayland, you usually can forget
> > characterwise resizing of frames: Wayland officially does not support
> > size increment hints like X11 and there's no way to tell it to resize
> > frames in increments of character sizes only.  In fact, you should
> > probably set 'frame-resize-pixelwise' to t, this might help when
> > toggling fullscreen.
> >
> > Though: I tried here with Plasma Wayland and it apparently does obey
> > size increments.  This might be a KWin peculiarity so if you are using
> > another desktop or WM your results will likely differ.  Which desktop/WM
> > do you use?
> >
> > martin
>
>
>
> --
> With best regards,
> Yurii Pytomets
>

[Message part 2 (text/html, inline)]

Message #26 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Sat, 20 Sep 2025 10:43:54 +0200

> So could there be a workaround for Wayland: e.g. correct margins
> pixel-wise so that would compensate for a gap between the frame size
> and an appropriate window size with the whole number of rows and
> columns?

We don't have margins at the top or bottom of a window and even the
margins at the left and right of a window can be specified only in
multiples of character widths.

You could play around with

(set-frame-parameter nil 'internal-border-width 16)

to something that fixes the height difference.  It will reduce the width
of windows by the same amount - if you can live with that.  And you
would have to do it from some hook - say 'window-size-change-functions'
- tracing any change in the height of your frames.

martin

Message #29 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Sat, 20 Sep 2025 10:44:20 +0200

> $ echo $XDG_CURRENT_DESKTOP
> ubuntu:GNOME

I was afraid so.  In my experience GNOME, GTK and Emacs do not get along.

> Actually, that would be great to have a single character-wise option to
> prohibit ANY pixel-wise behavior: that would be much more sustainable then
> debug and catch each package that affect window creating/resizing/scrolling
> and produce jumping-the-mess-around behavior.

Emacs operates characterwise by default with very few exceptions - GUI
dragging lines with the mouse being one of them.  I am not aware of any
packages changing that - can you tell me which?  And what precisely is
the "jumping-the-mess-around" behavior these cause?

martin

Message #32 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: Yurii Pytomets <pitometsu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Sat, 20 Sep 2025 17:56:24 +0300

Thank you.  Could that 16px gap be the result of the window title frame?
How could I debug to find what actually caused that (probably it
should be fixed, not just put a workaround in the setup that could not
work on other platforms)?

On Sat, Sep 20, 2025 at 11:44 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
> > $ echo $XDG_CURRENT_DESKTOP
> > ubuntu:GNOME
>
> I was afraid so.  In my experience GNOME, GTK and Emacs do not get along.
>
> > Actually, that would be great to have a single character-wise option to
> > prohibit ANY pixel-wise behavior: that would be much more sustainable then
> > debug and catch each package that affect window creating/resizing/scrolling
> > and produce jumping-the-mess-around behavior.
>
> Emacs operates characterwise by default with very few exceptions - GUI
> dragging lines with the mouse being one of them.  I am not aware of any
> packages changing that - can you tell me which?  And what precisely is
> the "jumping-the-mess-around" behavior these cause?
>
> martin
>


-- 
With best regards,
Yurii Pytomets

Message #35 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Sun, 21 Sep 2025 11:02:01 +0200

> Thank you.  Could that 16px gap be the result of the window title frame?

Your title bar seems to have more than 16 pixels so it would have to be
a rounding issue.  In Bug#52493 there was an problem with a font
(Inconsolata or so) that eventually caused continuous shrinking of a
frame (when demaximizing it, IIRC).  Can you try turning off the title
bar or change its font or size?  If so, would that have any impact on
the size of the Emacs frame?

> How could I debug to find what actually caused that (probably it
> should be fixed, not just put a workaround in the setup that could not
> work on other platforms)?

There are many issues I don't understand yet.  Please use emacs -Q for
the following tests:

- Does dragging a frame border with the mouse resize the frame in pixel
  increments or in larger ones?  Does that behavior change when setting
  'frame-resize-pixelwise' to t?

- Does a second frame made via C-x 5 2 show the same symptoms?

- Does setting 'frame-resize-pixelwise' to t affect the "shrinking when
  demaximizing issue"?

- When you turn off tool bars, menu bars or scroll bars, does the frame
  resize accordingly or does its size stay fixed?  If it resizes, does
  the 16 pixel gap persist or does it change?

- Can you try with a GTK-3 X11 build?

- Can you try with another desktop manager (XFCE should now have a
  Wayland backend and should be less expensive than Plasma)?  I do have
  GNOME on my other partition but upgraded there to trixie a week ago
  which apparently broke it (and KDE too) so I'm of no help here in the
  foreseeable future.

Also, Emacs has the variable 'frame-size-history' which you can set
ideally via

emacs -Q --eval "(setq frame-size-history t)"

Then you can call the function 'frame--size-history' which prints a
history of frame size changes into a buffer "*frame-size-history*".
Maybe that can be used to reveal what's going on.

Note that any work you do here would be highly appreciated but in most
similar occasions it turned out to be quite frustrating.

martin

Message #38 received at 79443 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Yurii Pytomets <pitometsu <at> gmail.com>
Cc: 79443 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79443: 30.2; Window frame not whole number of lines
Date: Tue, 23 Sep 2025 19:20:30 +0200

[Message part 1 (text/plain, inline)]

> So could there be a workaround for Wayland: e.g. correct margins
> pixel-wise so that would compensate for a gap between the frame size
> and an appropriate window size with the whole number of rows and
> columns?

We could always offload the extra pixels to the minibuffer window.
Patch attached.  It obviously won't work when separate minibuffer frames
are used.

martin

[Pytomets.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.