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

[Stefan Monnier]

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

>> Could we use a name that's "closer" then?
> Please suggest a better name.

`window-body-width` sounds good to me ;-)

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.

>> 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, which
is why I suggest bringing them closer so there's a higher chance that
they're exposed to the choice.

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

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


        Stefan