GNU bug report logs - #70894
[PATCH] * lisp/window.el (fit-window-to-buffer): Fix width calculation

Previous Next

Package: emacs;

Reported by: Morgan Smith <Morgan.J.Smith <at> outlook.com>

Date: Sun, 12 May 2024 13:31:01 UTC

Severity: normal

Tags: patch

Done: Morgan Smith <Morgan.J.Smith <at> outlook.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Morgan.J.Smith <at> outlook.com, 70894 <at> debbugs.gnu.org
Subject: bug#70894: [PATCH] * lisp/window.el (fit-window-to-buffer): Fix width calculation
Date: Sun, 19 May 2024 11:09:29 +0300
> Date: Sun, 19 May 2024 09:58:58 +0200
> Cc: 70894 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > Martin, any comments?
> 
> Looks good to me.  Principally, instead of subtracting the sizes of the
> decorations from the initial total width and re-adding them later, they
> should have been added to the calculated pixel width as is done when
> fitting the height.

OK, I installed the patch on master now, thanks.

> But mildly spoken, 'fit-window-to-buffer' is a complete mess in the
> first place.  Calculating sizes in terms of lines/columns doesn't make
> sense.  If really necessary - minibuffer resizing, for example, does not
> care - results should be rounded in a final step.  Also, I doubt that
> both char-width and char-height are calculated reasonably when buffer
> text is scaled or line spacing changed.

For the last issue: we should use default-font-width/height.  But the
question is: would replacing frame-char-width/height by these two fix
that use case, or do we need anything else?




This bug report was last modified 145 days ago.

Previous Next


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