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

[Jim Porter <jporterbugs@gmail.com>]

On 6/2/2022 11:31 PM, Eli Zaretskii wrote:
> 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.

While I don't have a strong opinion that this function should exist, I 
think the scenario where it *could* be useful is to "make layout 
decisions", as the Lisp manual says (for `window-max-chars-per-line'). 
If you were making some UI in a Lisp program that wanted things to fit 
in a window all at once, you'd likely know what face would get used (and 
it might not be the default face). Then, you could use both 
`window-max-chars-per-line' and `window-max-lines' to figure out how 
much space you have.

If that's not convincing, then let's do something more like what you 
suggest below.

> 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?

That works fine for me. I was actually surprised that these functions 
didn't account for face remapping.

Since window-body-(width|height) are C functions, it would be a bit more 
work to implement this, but I'm sure someone familiar with writing 
C-based Lisp functions wouldn't have much trouble. I could probably 
figure out how to do it myself with a bit of digging too.

>> +  (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?

I think integer division is right, but there's an argument either way. I 
see this function as asking the question, "How many lines can fully fit 
in this window without scrolling?" If I had a GUI terminal window open 
and it could fit 20.5 lines, I'd expect the $LINES variable in my shell 
to be 20. That way, a program that consults that variable would know 
that the 21st line is at least partly off-screen.