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.