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

[Jim Porter]

On 6/3/2022 11:20 PM, Eli Zaretskii wrote:
> I suggest that you try, it shouldn't be too hard.  Look at what
> window-font-height does, its main job is done in C as well, so you can
> call those functions directly from C, or do the same "by hand".  Feel
> free to ask questions if something is not clear.

Ok, here's an updated patch. Hopefully I got everything reasonably close 
to correct. I chose to add a new meaning for the PIXELWISE argument to 
`window-body-(width|height)' (and rename it to UNIT), since each of the 
three cases (canonical character size, remapped character size, and 
pixels) are all mutually-exclusive.

> > > Is integer division here really TRT?  Shouldn't we round to the
> > > nearest integer instead of truncating?
[snip]
> My point is that "partly off-screen" might mean 1 or 2 pixels
> off-screen, something that users will usually not even see, because
> those pixels are unused by most glyphs.  So maybe some heuristics is
> more pertinent, like rounding up only when the result is "almost" one
> more line.
>
> But if you are okay with "losing" a line in these cases, it's fine by
> me.

Since `window-body-(width|height)' round down by default, I think it 
makes sense to do that when those functions account for face remapping 
as well. Either rounding behavior would probably be ok for Eshell, but 
this way seems like the least surprising to users of these functions in 
general.

0001-Account-for-remapped-faces-in-COLUMNS-and-LINES-in-E.patch
Description: Text document