unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Aaron Jensen <aaronjensen@gmail.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 56102@debbugs.gnu.org
Subject: bug#56102: 29.0.50; fit-frame-to-buffer's window-text-pixel-size calculation can be incorrect when only is set to vertically
Date: Thu, 23 Jun 2022 09:30:26 +0200	[thread overview]
Message-ID: <0807c810-af05-f92c-17ce-991056906629@gmx.at> (raw)
In-Reply-To: <CAHyO48zHhO7uPHq2BBX7UnM_rXW-OBBN=pj=f6aTwx7Xi49dcg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

 >>> The problem appears to be the lines:
 >>>
 >>> (size
 >>>              (window-text-pixel-size window from to max-width max-height))
 >>>
 >>> As the max-width will be larger than the current frame (meaning the
 >>> height calculation will not take wrapping into account).

I think MAX-WIDTH should be nil here.

 >>> One possible fix is to set min/max height/width based on `only' to
 >>> (frame-parameter frame 'width) / (frame-parameter frame 'height) but I
 >>> do not know if that is the best fix.

This would not work.  The 'height' frame parameter counts in characters
while 'window-text-pixel-size' wants pixels as X-LIMIT.  Also, the sizes
of frame and window decorations would hardly match.

 >>> If that is done, then it may be possible to remove the rest of the
 >>> special handling for `only' that sets width/height to nil and handles that.
 >>
 >> I think you're right, but I'd like to hear if Martin has any comments.
 >
 > Sounds good. The most minimal change I can think of is to use the
 > current frame's width as max-width in the window-text-pixel-size call
 > when only is set to vertically. I don't know of any reason we need to
 > constrain max-height in that call because it doesn't have the same
 > impact. That can be done either explicitly in that call or by changing
 > max-width to be set to the current width as I described before. That
 > would be asymmetrical with max-height though, which would be rather
 > confusing IMO.

Please try the attached diff.

Thanks, martin

[-- Attachment #2: fit-frame-to-buffer.diff --]
[-- Type: text/x-patch, Size: 1413 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 1b8fe2b262..7b8ca87f6a 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -9382,14 +9382,17 @@ fit-frame-to-buffer-1
              ((numberp (nth 1 sizes)) (* (nth 1 sizes) line-height))
              (t (window-min-size window nil nil t))))
            (max-width
-            (min
-             (cond
-              ((numberp max-width) (* max-width char-width))
-              ((numberp (nth 2 sizes)) (* (nth 2 sizes) char-width))
-              (t parent-or-display-width))
-             ;; The following is the maximum width that fits into the
-             ;; left and right margins.
-             (max (- right-margin left-margin outer-minus-body-width))))
+            (let ((max-width
+                   (cond
+                    ((numberp max-width) (* max-width char-width))
+                    ((numberp (nth 2 sizes)) (* (nth 2 sizes) char-width))
+                    ((not (eq only 'vertically)) parent-or-display-width))))
+              (when (numberp max-width)
+                (min max-width
+                     ;; The following is the maximum width that fits
+                     ;; into the left and right margins.
+                     (max (- right-margin left-margin
+                             outer-minus-body-width))))))
            (min-width
             (cond
              ((numberp min-width) (* min-width char-width))

  reply	other threads:[~2022-06-23  7:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20  3:03 bug#56102: 29.0.50; fit-frame-to-buffer's window-text-pixel-size calculation can be incorrect when only is set to vertically Aaron Jensen
2022-06-22 13:58 ` Eli Zaretskii
2022-06-22 14:15   ` Aaron Jensen
2022-06-23  7:30     ` martin rudalics [this message]
2022-06-24  2:28       ` Aaron Jensen
2022-06-24  9:20         ` martin rudalics
2022-06-24 14:28           ` Aaron Jensen
2022-06-26 10:09             ` martin rudalics
2022-06-26 13:12               ` Aaron Jensen
2022-06-27  8:24                 ` martin rudalics
2022-06-27 13:24                   ` Aaron Jensen
2022-06-28  9:29                     ` martin rudalics
2022-06-28 14:52                       ` Aaron Jensen
2022-07-05 13:07                         ` Aaron Jensen
2022-07-06  7:37                           ` martin rudalics
2022-07-06 13:17                             ` Aaron Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0807c810-af05-f92c-17ce-991056906629@gmx.at \
    --to=rudalics@gmx.at \
    --cc=56102@debbugs.gnu.org \
    --cc=aaronjensen@gmail.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).