GNU bug report logs - #28915
Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels)

Previous Next

Package: emacs;

Reported by: Bob Weiner <rsw <at> gnu.org>

Date: Fri, 20 Oct 2017 17:43:01 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Bob Weiner <rsw <at> gnu.org>
Subject: bug#28915: closed (Re: bug#28915: Emacs 27 under macOS window
 system; improper frame resizing (off by 4 pixels))
Date: Tue, 31 Oct 2017 08:43:03 +0000
[Message part 1 (text/plain, inline)]
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 28915 <at> debbugs.gnu.org.

-- 
28915: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28915
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: martin rudalics <rudalics <at> gmx.at>
To: Bob Weiner <rsw <at> gnu.org>, 28915-done <at> debbugs.gnu.org
Subject: Re: bug#28915: Emacs 27 under macOS window system; improper frame
 resizing (off by 4 pixels)
Date: Tue, 31 Oct 2017 09:42:04 +0100
> 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



[Message part 3 (message/rfc822, inline)]
From: Bob Weiner <rsw <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 27 under macOS window system;
 improper frame resizing (off by 4 pixels)
Date: Fri, 20 Oct 2017 13:41:44 -0400
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





This bug report was last modified 7 years and 263 days ago.

Previous Next


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