|
From: | GNU bug Tracking System |
Subject: | [debbugs-tracker] bug#28915: closed (Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels)) |
Date: | Tue, 31 Oct 2017 08:43:02 +0000 |
Your message dated Tue, 31 Oct 2017 09:42:04 +0100 with message-id <address@hidden> and subject line Re: bug#28915: Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels) has caused the debbugs.gnu.org bug report #28915, regarding Emacs 27 under macOS window system; improper frame resizing (off by 4 pixels) to be marked as done. (If you believe you have received this mail in error, please contact address@hidden) -- 28915: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28915 GNU Bug Tracking System Contact address@hidden with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---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
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |