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

[Eli Zaretskii]

> Cc: 55696@debbugs.gnu.org, jeff.kowalski@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Fri, 3 Jun 2022 13:30:01 -0700
> 
> 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.

Layout decisions for a single line are much simpler, and more probable
to succeed, than similar layout decisions for the entire window.  The
latter are all but impossible to do from Lisp, definitely not with a
simplistic assumption of a single typeface being used for all the text
in the window.  We have window-text-pixel-size for the general case,
for that very reason.  But I think that function doesn't solve your
problem, because you don't have text to measure when you make these
decisions.

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

There's no need to take face remapping into account as long as you
measure in units of canonical character width and height.  Face
remapping is local to buffers, so it usually makes no sense to take
the remapping into account by default, because a window can display
any buffer.

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

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.

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

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.

Thanks.