GNU bug report logs - #38705
26.3; set-frame-size pixelwise makes frame larger

Previous Next

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

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

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

From: ynyaaa <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; set-frame-size pixelwise makes frame larger
Date: Sun, 22 Dec 2019 21:36:50 +0900

set-frame-size with PIXELWISE=t makes frame larger than specified value.
(setq frame-resize-pixelwise t) makes no difference.

(progn (set-frame-size nil 500 500 t)
       (list (list (frame-outer-width)
                   (frame-pixel-width)
                   (frame-inner-width))
             (list (frame-outer-height)
                   (frame-pixel-height)
                   (frame-inner-height))))
=>((549 533 533) (595 536 536))

(progn (set-frame-size nil 1000 1000 t)
       (list (list (frame-outer-width)
                   (frame-pixel-width)
                   (frame-inner-width))
             (list (frame-outer-height)
                   (frame-pixel-height)
                   (frame-inner-height))))
=>((1049 1033 1033) (1095 1036 1036))



In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Recent messages:

Making completion list...

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

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

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 emacsbug tabify network-stream nsm starttls tls gnutls mailalias
smtpmail auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
sendmail sort cus-edit wid-edit cus-start cus-load cl-extra thingatpt
help-fns radix-tree info mail-extr message rmc puny seq dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader help-mode easymenu
cl-print byte-opt gv bytecomp byte-compile cl-loaddefs cl-lib cconv
debug rect misearch multi-isearch elec-pair time-date mule-util
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 menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 minibuffer 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 153461 39548)
 (symbols 48 24728 1)
 (miscs 40 107 477)
 (strings 32 47512 1964)
 (string-bytes 1 1134114)
 (vectors 16 21297)
 (vector-slots 8 994377 94862)
 (floats 8 68 408)
 (intervals 56 1272 243)
 (buffers 992 19))

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

From: martin rudalics <rudalics <at> gmx.at>
To: ynyaaa <at> gmail.com, 38705 <at> debbugs.gnu.org
Subject: Re: bug#38705: 26.3; set-frame-size pixelwise makes frame larger
Date: Mon, 23 Dec 2019 11:08:14 +0100

> set-frame-size with PIXELWISE=t makes frame larger than specified value.
> (setq frame-resize-pixelwise t) makes no difference.
>
> (progn (set-frame-size nil 500 500 t)
>         (list (list (frame-outer-width)
>                     (frame-pixel-width)
>                     (frame-inner-width))
>               (list (frame-outer-height)
>                     (frame-pixel-height)
>                     (frame-inner-height))))
> =>((549 533 533) (595 536 536))

Right.  But here

(progn (set-frame-size nil 500 500 t)
       (list (list (frame-outer-width)
                   (frame-pixel-width)
                   (frame-inner-width)
		   (frame-text-width))
             (list (frame-outer-height)
                   (frame-pixel-height)
                   (frame-inner-height)
		   (frame-text-height))))
=>((540 532 532 500) (583 536 536 500))

This is because 'set-frame-size' sets "the size of the text area of
FRAME" and the size of the text area is returned by 'frame-text-width'
and 'frame-text-height'.  Just another Emacs idiosyncrasy ...

martin

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

From: ynyaaa <at> gmail.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38705 <at> debbugs.gnu.org
Subject: Re: bug#38705: 26.3; set-frame-size pixelwise makes frame larger
Date: Tue, 24 Dec 2019 22:49:55 +0900

martin rudalics <rudalics <at> gmx.at> writes:

> Right.  But here
>
> (progn (set-frame-size nil 500 500 t)
>        (list (list (frame-outer-width)
>                    (frame-pixel-width)
>                    (frame-inner-width)
>                    (frame-text-width))
>              (list (frame-outer-height)
>                    (frame-pixel-height)
>                    (frame-inner-height)
>                    (frame-text-height))))
> =>((540 532 532 500) (583 536 536 500))
>
> This is because 'set-frame-size' sets "the size of the text area of
> FRAME" and the size of the text area is returned by 'frame-text-width'
> and 'frame-text-height'.  Just another Emacs idiosyncrasy ...
>
> martin

I tried to set up the frame outer size like below.
  ;;; sample ~/.emacs.d/init.el
  (defun test-set-frame-outer-size (frame width height)
    (set-frame-size frame width height t)
    (set-frame-size frame
                    (- width  (- (frame-outer-width  frame) width))
                    (- height (- (frame-outer-height frame) height))
                    t))
  (setq frame-inhibit-implied-resize t)
  (test-set-frame-outer-size nil 500 500)
  ;;; sample ~/.emacs.d/init.el end

But the function does not work well inside init.el.
After emacs started, the size is:
  (list (frame-outer-width) (frame-outer-height))
  =>(500 502)
When user input is allowed, evaluating
  (test-set-frame-outer-size nil 500 500)
works as expected.

About another point.
If the frame has no menu-bar, tool-bar, scroll-bar nor fringes,
frame-pixel-width and frame-pixel-height can be set by set-frame-size.
But if the frame is undecorated, the outer size is as large as the size
of non-undecorated frame regardless of the value of
frame-inhibit-implied-resize. 
The inner size is enlarged to the outer size after redisplay.
The size can not be set as expected.
  (let ((width 500) (height 500)
        (params '((undecorated . t)
                  (menu-bar-lines . 0)
                  (tool-bar-lines . 0)
                  (horizontal-scroll-bars . nil)
                  (vertical-scroll-bars . nil)
                  (left-fringe . 0)
                  (right-fringe . 0)))
        (f (lambda () (list (list (frame-outer-width)
                                  (frame-inner-width))
                            (list (frame-outer-height)
                                  (frame-inner-height))))))
    (setq frame-inhibit-implied-resize t)
    (modify-frame-parameters nil params)
    (set-frame-size nil width height t)
    (list (funcall f)
          (progn (redisplay) (funcall f))))
  =>(((516 500) (539 500)) ((516 516) (539 539)))

If the form above is evaluated twice, the frame outer size stays
516x539 pixels and the inner size shrinks to 500x500 pixels.
The inner text area is displayed at the top-left,
and there are blank areas at the right and the bottom.

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

From: martin rudalics <rudalics <at> gmx.at>
To: ynyaaa <at> gmail.com
Cc: 38705 <at> debbugs.gnu.org
Subject: Re: bug#38705: 26.3; set-frame-size pixelwise makes frame larger
Date: Wed, 25 Dec 2019 10:49:34 +0100

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

> I tried to set up the frame outer size like below.
>    ;;; sample ~/.emacs.d/init.el
>    (defun test-set-frame-outer-size (frame width height)
>      (set-frame-size frame width height t)
>      (set-frame-size frame
>                      (- width  (- (frame-outer-width  frame) width))
>                      (- height (- (frame-outer-height frame) height))
>                      t))
>    (setq frame-inhibit-implied-resize t)
>    (test-set-frame-outer-size nil 500 500)
>    ;;; sample ~/.emacs.d/init.el end
>
> But the function does not work well inside init.el.
> After emacs started, the size is:
>    (list (frame-outer-width) (frame-outer-height))
>    =>(500 502)
> When user input is allowed, evaluating
>    (test-set-frame-outer-size nil 500 500)
> works as expected.

Look up the function 'frame-geometry'.  If its return value for
something like the 'external-border-size' differs for a frame before
and after "user input is allowed" then it's because that something has
not been specified before the frame was "mapped" and so Emacs won't
know it.

If you are sure that your decorations won't change from one emacs
session to the next, you can try to remember them from the last
session and apply them manually.  However, in general, calling
'frame-outer-width/-height' from init.el is not a good idea.

> About another point.
> If the frame has no menu-bar, tool-bar, scroll-bar nor fringes,
> frame-pixel-width and frame-pixel-height can be set by set-frame-size.
> But if the frame is undecorated, the outer size is as large as the size
> of non-undecorated frame regardless of the value of
> frame-inhibit-implied-resize.
> The inner size is enlarged to the outer size after redisplay.
> The size can not be set as expected.
>    (let ((width 500) (height 500)
>          (params '((undecorated . t)
>                    (menu-bar-lines . 0)
>                    (tool-bar-lines . 0)
>                    (horizontal-scroll-bars . nil)
>                    (vertical-scroll-bars . nil)
>                    (left-fringe . 0)
>                    (right-fringe . 0)))
>          (f (lambda () (list (list (frame-outer-width)
>                                    (frame-inner-width))
>                              (list (frame-outer-height)
>                                    (frame-inner-height))))))
>      (setq frame-inhibit-implied-resize t)
>      (modify-frame-parameters nil params)
>      (set-frame-size nil width height t)
>      (list (funcall f)
>            (progn (redisplay) (funcall f))))
>    =>(((516 500) (539 500)) ((516 516) (539 539)))
>
> If the form above is evaluated twice, the frame outer size stays
> 516x539 pixels and the inner size shrinks to 500x500 pixels.

Please note again that the values you pass to 'set-frame-size' are the
values later reported by 'frame-text-width' and 'frame-text-height'.
These are fictive values and neither inner, nor outer or native sizes
might match these.

> The inner text area is displayed at the top-left,
> and there are blank areas at the right and the bottom.

This is the result of a bug that made frame resizing incorrect for
undecorated frames on Windows ever since.  To explain why this bug
usually goes unnoticed note that 'set-frame-size' causes three things
to happen: (1) it asks the window manager to resize the frame's
(window system) window.  (2) it "prematurely" resizes the frame's
windows because in their code some users want to know the new window
sizes right away.

Now if (1) eventually results in a frame size different from the one
expected in (2), the corresponding message from the window manager
will cause Emacs to (3) re-resize the frame's windows if they don't
match and everything should go well.  Usually, the sizes returned by
the window manager match those expected by (2) and in (3) no such
re-resizing is needed.

But in your scenario the first

(set-frame-size nil 500 500 t)

call will, due to the bug, pass incorrect values to the window
manager, which makes the values eventually returned by the window
manager differ from those calculated in (2).  (3) will fix this.  But
the subsequent calls will cause the window manager do nothing in (1)
because it is supplied the old values again and thus will decide that
no resizing is needed.  Yet Emacs will perform (2) with the values it
expects and these values will never be corrected because (3) will
never happen.

Please try the attached patch.  I will install it on Emacs-27 as soon
as I have upgraded my working environment, something which may happen
in a couple of days only.

Many thanks again for reporting these obscure behaviors, martin

[w32fns.c.diffs (text/plain, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: ynyaaa <at> gmail.com
Cc: 38705 <at> debbugs.gnu.org
Subject: Re: bug#38705: 26.3; set-frame-size pixelwise makes frame larger
Date: Thu, 2 Jan 2020 09:52:18 +0100

tags 38705 fixed
close 38705 27.1
quit

> Please try the attached patch.  I will install it on Emacs-27 as soon
> as I have upgraded my working environment, something which may happen
> in a couple of days only.

Installed.  Closing this bug.

Thanks again for the report, martin

Previous Next

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