On Fri, Nov 4, 2011 at 9:02 AM, Eli Zaretskii
<eliz@gnu.org> wrote:
[Please don't remove debbugs from the CC list.]
Oops, sorry.
> > 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:
It's trying to set the ERC fill column such that there will be room to insert a timestamp aligned to the right edge of the window. That code was only an example to show how incorrect window-width can break things. I really want a version of window-width that behaves as I described.
> 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.
I'd prefer to avoid the save-excursion-and-move-point dance so I could avoid checking conditions like being at start or end of buffer, whether forward-char actually moved horizontally or did it go to the next line, etc. This approach also wouldn't work in buffers that were empty, for example in a find-file-hook on a new file, because we can't move the point without modifying the buffer. It would be much simpler and more reliable to expose faces' pixel widths.
> 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?
window-width already returns incorrect results for the exceptions you mentioned. A variant that accounts for text scaling would be correct in all the cases window-width is correct, plus the case where text scaling has been applied to a fixed width font. All that is needed is for someone to expose the pixel width of a face and my scaled-window-width function above will work.