Re: master 91418d27e9: Add new functions for computing character metrics for windows

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org,  malsburg@posteo.de,  emacs-devel@gnu.org
> Date: Sat, 30 Apr 2022 10:34:58 -0400
> 
> >> But admittedly, in most cases you can use
> >> `window-max-characters-per-line only` as a heuristic because of the
> >> effect of proportional fonts
> > What else can you do when proportional fonts are used, except account
> > fro the average width?
> 
> Indeed.  But it just means that (unless you do the kind of job that
> Lars did in vtable and SHR) the code will always be somewhat broken, and
> the difference between using `window-max-characters-per-line` or
> `window-body-width` is in which cases it's broken.

Emacs is still 85% fixed-pitch.  We still don't "have the technology"
to work with variable-pitch fonts as simply and efficiently as with
fixed-pitch.  In this situation, lamenting the fact that an API is
less helpful with variable-pitch fonts strikes me as a clear case of
premature optimization.

> >> and faces
> > The function accepts FACE as the argument.  So this is accounted for.
> 
> I think you missed to "applied to specific parts of the text":

No, I didn't.  If someone needs to use text with different faces, then
calling this function is a mistake.  Any API can be used mistakenly,
but that fact doesn't yet mean the API is not useful when used
correctly.

> > (And I wonder why this sudden crusade against this function.)
> 
> For one, because it's name makes it impossible to find when you're
> looking for "one of those functions that returns some notion of text
> width".

I disagree.  But anyway, if you or someone can come up with a better
name, and do it soon enough, we can easily rename it.

> For two, because this was already a nasty mess and this function just
> adds insult to injury, IMO.

I cannot disagree more.  The function has a place and serves a class
of use cases well enough to be justified.  It prevents Lisp programs
from using low-level interfaces like font-get-glyphs etc., on the one
hand, and OTOH is simpler and faster than window-text-pixel-size.