Subject: bug#28915: closed (Re: bug#28915: Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels))

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 31 Oct 2017 08:43:03 +0000

Your bug report

#28915: Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels)

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
28915: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28915
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#28915: Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels)
From: martin rudalics <[email-masked]>
To: Bob Weiner <[email-masked]>, [email-masked]
Date: Tue, 31 Oct 2017 09:42:04 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

> This is not a bug.  For historic reasons, the second arguments of
> ‘set-frame-width’ and ‘set-frame-height’ must specify the width and
> height of the _text area_ of the frame and not its native width and
> height.  You can rely on this to never ever change.  Section 29.3.4
> Frame Size of the Elisp manual should explain everything.

Closing this bug.

martin

Subject: Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels)
From: Bob Weiner <[email-masked]>
To: [email-masked]
Date: Fri, 20 Oct 2017 13:41:44 -0400
List-Id: <debbugs-submit.debbugs.gnu.org>

Each time the following two expressions are called, they increase the
width or height respectively of the selected frame by 4 pixels rather
than leaving the dimension unchanged.  Even if this is a rounding error
due to use of column/line math, shouldn't there be a special case test
for this that prevents the size change?  It would simplify coding.

(progn (set-frame-width nil (frame-pixel-width) nil t)
       (frame-pixel-width))

(progn (set-frame-height nil (frame-pixel-height) nil t)
       (frame-pixel-height))

Bob