bug#55696: 28.1; eshell fails to respect text-scale-increase

[Eli Zaretskii]

> From: Jim Porter <jporterbugs@gmail.com>
> Date: Thu, 2 Jun 2022 21:41:33 -0700
> 
> > M-x text-scale-increase
> > ls /etc
> > 
> > At this point, the listing is very poorly wrapped.  It appears to ignore 
> > the increased width of the font relative to the width of the window
> 
> Thanks for the bug report. I think this patch fixes things. I added 
> `window-max-lines' as the Y-axis correspondent to the X-axis version 
> `window-max-chars-per-line'; maybe there's a function for this already, 
> but I didn't see one after a bit of searching.

Thanks, but I'm not too happy with adding such a function to Emacs.  I
understand why it could make sense for Eshell, or any other package
that uses fixed-size characters, like terminal emulators in term.el.
But in general, it makes no sense in Emacs to ask how many lines of a
given non-default font can fit in a window, because you cannot
guarantee that a single font will be used in the entire window -- it
is enough to have some of the text having the bold or italic face
attribute, or have some non-ASCII characters that will be displayed in
a different font, to disrupt the results.

We could perhaps make window-body-width and window-body-height
optionally pay attention to the remapping of the default face, which
should handle the case such as this one.  Would that be acceptable for
you?

> +  (with-selected-window (window-normalize-window window t)
> +    (let ((window-height (window-body-height window t))
> +       (font-height (window-font-height window face)))
> +      (/ window-height font-height))))

Is integer division here really TRT?  Shouldn't we round to the
nearest integer instead of truncating?