GNU bug report logs - #51975
29.0.50; fit-frame-to-buffer calculates frame width incorrectly on X11 with Gtk 3

Previous Next

Package: emacs;

Reported by: Arthur Miller <arthur.miller <at> live.com>

Date: Fri, 19 Nov 2021 15:40:02 UTC

Severity: normal

Found in version 29.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51975 in the body.
You can then email your comments to 51975 AT debbugs.gnu.org in the normal way.

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#51975; Package emacs. (Fri, 19 Nov 2021 15:40:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Arthur Miller <arthur.miller <at> live.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 19 Nov 2021 15:40:02 GMT) Full text and rfc822 format available.

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

From: Arthur Miller <arthur.miller <at> live.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; fit-frame-to-buffer calculates frame width incorrectly on
 X11 with Gtk 3
Date: Fri, 19 Nov 2021 16:20:22 +0100
[Message part 1 (text/plain, inline)]
The function calculates frame width one column too small in regard to
displayed buffer which results in text being wrapped around and extra line added
to the frame.

If you look at attached png image you will see backward slash and extra line
added below. Or you can run the attached .el file.

Simple fix I used was to add an extra column to the width of the frame
after I called fit-frame-to-buffer (commented away in the attached file).

The frame created is without any decorations, fringes, borders etc. I wanted as
"bare" X11 window as possible, so the misscalculation might be due to some
missing border or something, I haven't investigated myself.

This probably affects earlier Emacs versions too. I haven't tested other targets,
non-gtk or on other OS.

To reproduce save attached emacs-vision-clock.el somewhere and eval with
Emacs -Q. Example:

emacs -Q -l ./emacs-vision-clock.el --eval "(emacs-vision-clock-run)"&


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-11-17 built on pascal
Repository revision: 1ddebefc9fe178e9e8b4275a45e0eda1bcf7848e
Repository branch: alpha-patch
Windowing system distributor 'The X.Org Foundation', version 11.0.12101001
System Description: Arch Linux

Configured using:
 'configure --with-native-compilation 'CFLAGS=-O2 -march=native
 -mtune=native''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XPM GTK3 ZLIB

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

Major mode: Lisp Interaction

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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils emacs-vision-clock time-stamp help-mode
cl-loaddefs cl-lib iso-transl tooltip eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-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 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 71626 11134)
 (symbols 48 6834 0)
 (strings 32 20798 1615)
 (string-bytes 1 700953)
 (vectors 16 14697)
 (vector-slots 8 313076 18657)
 (floats 8 27 32)
 (intervals 56 216 0)
 (buffers 992 11))

[fit-frame-to-buffer-bug.png (image/png, attachment)]
[emacs-vision-clock.el (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51975; Package emacs. (Fri, 19 Nov 2021 18:13:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Arthur Miller <arthur.miller <at> live.com>, 51975 <at> debbugs.gnu.org
Subject: Re: bug#51975: 29.0.50; fit-frame-to-buffer calculates frame width
 incorrectly on X11 with Gtk 3
Date: Fri, 19 Nov 2021 19:12:23 +0100
> The function calculates frame width one column too small in regard to
> displayed buffer which results in text being wrapped around and extra line added
> to the frame.

See

‘no-special-glyphs’
     If this is non-‘nil’, it suppresses the display of any truncation
     and continuation glyphs (*note Truncation::) for all buffers
     displayed by this frame.  This is useful to eliminate such glyphs
     when fitting a frame to its buffer via ‘fit-frame-to-buffer’ (*note
     Resizing Windows::).

in section 30.4.3.4 Layout Parameters of the Elisp manual.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51975; Package emacs. (Fri, 19 Nov 2021 19:23:02 GMT) Full text and rfc822 format available.

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

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51975 <at> debbugs.gnu.org
Subject: Re: bug#51975: 29.0.50; fit-frame-to-buffer calculates frame width
 incorrectly on X11 with Gtk 3
Date: Fri, 19 Nov 2021 20:22:04 +0100
martin rudalics <rudalics <at> gmx.at> writes:

>> The function calculates frame width one column too small in regard to
>> displayed buffer which results in text being wrapped around and extra line added
>> to the frame.
>
> See
>
> ‘no-special-glyphs’
>      If this is non-‘nil’, it suppresses the display of any truncation
>      and continuation glyphs (*note Truncation::) for all buffers
>      displayed by this frame.  This is useful to eliminate such glyphs
>      when fitting a frame to its buffer via ‘fit-frame-to-buffer’ (*note
>      Resizing Windows::).
>
> in section 30.4.3.4 Layout Parameters of the Elisp manual.
>
> martin
Ah, allright; didn't know about that option :-).

I'll check and repport how it works in a bit.

Thanks!




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#51975; Package emacs. (Fri, 19 Nov 2021 19:41:01 GMT) Full text and rfc822 format available.

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

From: Arthur Miller <arthur.miller <at> live.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 51975 <at> debbugs.gnu.org
Subject: Re: bug#51975: 29.0.50; fit-frame-to-buffer calculates frame width
 incorrectly on X11 with Gtk 3
Date: Fri, 19 Nov 2021 20:39:54 +0100
martin rudalics <rudalics <at> gmx.at> writes:

>> The function calculates frame width one column too small in regard to
>> displayed buffer which results in text being wrapped around and extra line added
>> to the frame.
>
> See
>
> ‘no-special-glyphs’
>      If this is non-‘nil’, it suppresses the display of any truncation
>      and continuation glyphs (*note Truncation::) for all buffers
>      displayed by this frame.  This is useful to eliminate such glyphs
>      when fitting a frame to its buffer via ‘fit-frame-to-buffer’ (*note
>      Resizing Windows::).
>
> in section 30.4.3.4 Layout Parameters of the Elisp manual.
>
> martin

Indeed, it was it. With this parameter set to 't fit-frame-to-buffer works
correctly, so I guess it is not a bug. Sorry for the noise.




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Fri, 19 Nov 2021 19:52:01 GMT) Full text and rfc822 format available.

Notification sent to Arthur Miller <arthur.miller <at> live.com>:
bug acknowledged by developer. (Fri, 19 Nov 2021 19:52:01 GMT) Full text and rfc822 format available.

Message #19 received at 51975-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Arthur Miller <arthur.miller <at> live.com>
Cc: 51975-done <at> debbugs.gnu.org, rudalics <at> gmx.at
Subject: Re: bug#51975: 29.0.50;
 fit-frame-to-buffer calculates frame width incorrectly on X11 with
 Gtk 3
Date: Fri, 19 Nov 2021 21:51:32 +0200
> From: Arthur Miller <arthur.miller <at> live.com>
> Date: Fri, 19 Nov 2021 20:39:54 +0100
> Cc: 51975 <at> debbugs.gnu.org
> 
> martin rudalics <rudalics <at> gmx.at> writes:
> 
> > See
> >
> > ‘no-special-glyphs’
> >      If this is non-‘nil’, it suppresses the display of any truncation
> >      and continuation glyphs (*note Truncation::) for all buffers
> >      displayed by this frame.  This is useful to eliminate such glyphs
> >      when fitting a frame to its buffer via ‘fit-frame-to-buffer’ (*note
> >      Resizing Windows::).
> >
> > in section 30.4.3.4 Layout Parameters of the Elisp manual.
> >
> > martin
> 
> Indeed, it was it. With this parameter set to 't fit-frame-to-buffer works
> correctly, so I guess it is not a bug. Sorry for the noise.

Thanks, closing.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 18 Dec 2021 12:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 91 days ago.

Previous Next


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