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: Fri, 29 Apr 2022 16:40:03 -0400
> 
> Eli Zaretskii [2022-04-29 22:59:11] wrote:
> >> So, really it's just another variant of `window-body-width`?
> > Not really, no.
> 
> I'm not sure what you mean by that.

I mean that it isn't a variant of window-body-width.  It has a
different purpose and serves different use cases, as one can easily
see from the discussion of the bug which led to the change.

> I suspect that most potential users of this new function currently use
> `window-body-width` (tho many others probably use something even less
> adequate).

We don't know what they use.  I hope they use window-text-pixel-size.
Some probably use window-width (see the bug report) or maybe
window-edges.

> >> Could we use a name that's "closer" then?
> > Please suggest a better name.
> 
> `window-body-width` sounds good to me ;-)

I presumed this was a serious discussion.  Apologies for my
misunderstanding.

If this is a serious discussion, then window-body-width is NOT a good
name, because it basically would redefine what is a window's "body".

> BTW, I notice that `window-max-characters-per-line` doesn't deduct the
> space used by `display-line-number-mode`, whereas I'd expect most(?)
> users of that function to want to take this into account.

I'm not sure I understand the assumption, and I don't think I agree.
In any case, subtracting the line-number-width will give you what you
want.

> >> We should try and "bring together" all the window-foo-width variants so
> >> as to try and reduce the probability that someone uses the wrong one by
> >> accident.
> > The latter part is impossible.  Most Lisp programmers don't understand
> > the fine details and issues with different measures of "window-width",
> > and it's infeasible to teach them all that complexity.
> 
> In my experience the main problem is not so much that they don't
> understand those details but that they're not even aware of them

Is there a difference?

> which is why I suggest bringing them closer so there's a higher
> chance that they're exposed to the choice.

And you really think that exposing that will facilitate understanding?
I think it will proliferate confusion instead.

> >> Not completely sure what "bring together" should mean here.  Could be
> >> merge them into a single function with an extra argument describing
> >> which elements to include/exclude in the count, or it could be to place
> >> them all under the `window-width-` prefix, or includes links
> >> between them in their docstrings, ...
> >> And of course clearly describe the differences between them.
> >
> > IMNSHO, that way lies madness.  There are too many variations and too
> > many special cases.
> 
> It doesn't have to offer notably more choices.  I'd imagine a "window
> width" function with 2 args, one specifying the unit (e.g. pixels, the
> frame chars, or some face's chars) and another specifying which elements
> to include/exclude (with a handful of options corresponding to: the
> outer size, the size actually usable to display text coming from the
> buffer, and a few options in-between; i.e. corresponding to the existing
> functions `window-width`, `window-body-width`,
> `window-max-characters-per-line`, `window-text-width`,
> `window-total-width`).

Now multiply the number of units (3, and I'm not sure this is all) by
the number of alternatives regarding which elements to exclude (4 by
my count), and you get the total number of variations.  Is it
reasonable?

> >> Maybe in this case, instead of introducing a new function we should
> >> refine the "pixelwise" arg of `window-body-width` so we can choose
> >> between pixelwise, or based on the size of the frame's font, or based on
> >> the size of a particular face's font?
> > Why does it make sense to complicate a single API instead of having N
> > simpler APIs that do the different jobs?
> 
> I don't think it would complicate the API.
> 
> > What practical problem will this solve?
> 
> Try and reduce the confusion for programmers like me who find it
> difficult to even figure out which are the available options (e.g. I'm
> still not sure the above list of alternative functions is exhaustive).

See above.