bug#9949: 24.0.91; window-width function does not take text-scale-mode-amount into account

[Eli Zaretskii <eliz@gnu.org>]

[Please don't remove debbugs from the CC list.]

> > The code shown by the URL you cite should not use window-width.  It
> > should instead use posn-at-point after moving to the line end (e.g.,
> > with `end-of-visual-line').
> >
> 
> In the common case, lines are shorter than the window width, so after
> moving to end-of-visual-line, posn-at-point would contain the length of the
> current line and not the window width.  I don't see how this approach could
> work without modifying the buffer.

I don't really understand what the code on the page you pointed to
wants to do, so perhaps my suggestion was incorrect.  An alternative
is what Martin suggested:

> Recipe by courtesy of Johan Bockgård:
> 
> (insert (propertize
>               " " 'display
>               '(space :align-to (- text 8))) "#123456")


> (defun scaled-window-width ()
>   (destructuring-bind (left top right bottom) (window-inside-pixel-edges)
>     (/ (- right left) (face-pixel-width))))
> 
> Unfortunately, I could not find anything like face-pixel-width.  Is this
> information exposed somehow or could it be made so?

You could move point by 1 character and subtract pixel coordinates
returned by posn-at-point.

> For someone to be able to implement these new functions, you (or
> > someone else) should come up with a specification of what they should
> > return in the presence of different faces in the window.  E.g., should
> > the function that returns the line's width return values for a
> > specific line, rather than for a window as a whole?  should it count
> > characters in that line or something else?  etc., etc.
> >
> 
> Basing the result on the width of the face at point seems reasonable, with
> a caveat in the docstring about windows having faces of different widths.

But given that a line can have characters of different width, even for
the same face (think proportional fonts), what good will this kind of
functionality be?