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

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

[Stefan Monnier]

Lars Ingebrigtsen [2022-04-29 09:15:10] wrote:
> ++++
> +** New function 'window-max-characters-per-line'.
> +
> ++++
> +** New function 'window-char-pixel-width'.
> +
> ++++
> +** New function 'window-char-pixel-width'.

Any reason not to group them under the same heading?

> +    (let* ((face (if face face 'default))

(or face 'default) ?

> +	   (info (font-info (face-font face)))
> +	   (width (aref info 11)))
> +      (if (> width 0)
> +	  width
> +	(aref info 10)))))

Any chance we could have a `cl-defstruct` for those font-info objects, so
we can use names rather than magic constants?  Alternatively a short
comment here explaining the difference between 11 and 10 would be nice.

> +(defun window-max-characters-per-line (&optional window face)

The name says "max", but AFAICT it's basically "window width / *average*
char width", so it's not really the "max" number of chars (unsurprisingly).

I'm not sure how best to name it (and document it), tho.
For that I think I'd need to know what are the use cases (to see what
property they rely on).


        Stefan

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Any reason not to group them under the same heading?

I thought the "probably introduced" thing only looked in the headings?
And they were too long for one heading.

>> +    (let* ((face (if face face 'default))
>
> (or face 'default) ?

Yup; now done.

> Any chance we could have a `cl-defstruct` for those font-info objects, so
> we can use names rather than magic constants?  Alternatively a short
> comment here explaining the difference between 11 and 10 would be nice.

Sure, a defstruct would be nice.

>> +(defun window-max-characters-per-line (&optional window face)
>
> The name says "max", but AFAICT it's basically "window width / *average*
> char width", so it's not really the "max" number of chars (unsurprisingly).
>
> I'm not sure how best to name it (and document it), tho.
> For that I think I'd need to know what are the use cases (to see what
> property they rely on).

The use case basically is that you want to draw monospaced things that
aren't too wide, but the function was made a bit more general.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

Lars Ingebrigtsen [2022-04-29 15:53:48] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Any reason not to group them under the same heading?
> I thought the "probably introduced" thing only looked in the headings?

Oh, no, it just performs a very naive regexp search over the whole text.

>>> +(defun window-max-characters-per-line (&optional window face)
>>
>> The name says "max", but AFAICT it's basically "window width / *average*
>> char width", so it's not really the "max" number of chars (unsurprisingly).
>>
>> I'm not sure how best to name it (and document it), tho.
>> For that I think I'd need to know what are the use cases (to see what
>> property they rely on).
> The use case basically is that you want to draw monospaced things that
> aren't too wide, but the function was made a bit more general.

So, really it's just another variant of `window-body-width`?
Could we use a name that's "closer" then?

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.

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.

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?


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Titus von der Malsburg <malsburg@posteo.de>,  emacs-devel@gnu.org
> Date: Fri, 29 Apr 2022 10:55:09 -0400
> 
> So, really it's just another variant of `window-body-width`?

Not really, no.

> Could we use a name that's "closer" then?

Please suggest a better name.

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

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

> 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?  What practical problem will
this solve?

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

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.

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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 could add that, but display-line-number-mode is per buffer, while
this is a window function, so it doesn't quite seem natural.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

Lars Ingebrigtsen [2022-04-30 13:12:55] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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 could add that, but display-line-number-mode is per buffer, while
> this is a window function, so it doesn't quite seem natural.

I know.  And it's worse because that width can vary over time.

But admittedly, in most cases you can use
`window-max-characters-per-line only` as a heuristic because of the
effect of proportional fonts, compositions, and faces applied to
specific parts of the text.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  malsburg@posteo.de,  emacs-devel@gnu.org
> Date: Sat, 30 Apr 2022 09:33: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?

> compositions

Irrelevant.  The function says how many character cells are available
for displaying text, not how many codepoints can be squeezed there.

> and faces

The function accepts FACE as the argument.  So this is accounted for.

(And I wonder why this sudden crusade against this function.)

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

[Stefan Monnier]

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

>> 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": the FACE
argument only handles the case where the whole line uses that same face.

> (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".
For two, because this was already a nasty mess and this function just
adds insult to injury, IMO.


        Stefan

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.

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

[Stefan Monnier]

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

That's not my point.  All I'm saying is that it's just another function
that does the ~90% work.  Maybe it's a bit closer to 100% but that
doesn't make it qualitatively different and that makes it part of the
same family as those other functions.  And having such wildly different
naming between those functions is not helpful.

> No, I didn't.  If someone needs to use text with different faces, then
> calling this function is a mistake.

Most of the code that will want to use this function can be confronted
with text with different faces completely out of its control
(e.g. because of hi-lock, goto-address-mode, you name it).
So you're saying that in practice most uses are "a mistake".

> Any API can be used mistakenly, but that fact doesn't yet mean the API
> is not useful when used correctly.

I think you misunderstand me: I'm not at all opposed to the
functionality offered by this new function.

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

I think it should match window-*-width since that's the most common
pattern shared by other functions in that family, AFAICT.

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

I'm not arguing against the new functionality.
I'm arguing against the way it's exposed.


        Stefan

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 11:52:44 -0400
> 
> > 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.
> 
> That's not my point.  All I'm saying is that it's just another function
> that does the ~90% work.

Any function that deals with integer columns and lines will never be
able to do a 100% job.  And yet we have quite a few of those, and they
are used all over, with generally good results.

> > No, I didn't.  If someone needs to use text with different faces, then
> > calling this function is a mistake.
> 
> Most of the code that will want to use this function can be confronted
> with text with different faces completely out of its control
> (e.g. because of hi-lock, goto-address-mode, you name it).
> So you're saying that in practice most uses are "a mistake".

That's not the use case this function supports.  It supports the use
case where some Lisp program produces text under its control, and
wants to know how much of the text can be put on a single screen line.

> > 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.
> 
> I'm not arguing against the new functionality.
> I'm arguing against the way it's exposed.

The way it's exposed reflects the needs of the use cases it serves.

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

[Stefan Monnier]

>> (e.g. because of hi-lock, goto-address-mode, you name it).
>> So you're saying that in practice most uses are "a mistake".
>
> That's not the use case this function supports.  It supports the use
> case where some Lisp program produces text under its control, and
> wants to know how much of the text can be put on a single screen line.

hi-lock and goto-address-mode are minor modes; they can apply just as
well to that "produced text under its control".

> The way it's exposed reflects the needs of the use cases it serves.

Oh well,


        Stefan