[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Josh
Subject: bug#9949: 24.0.91; window-width function does not take text-scale-mode-amount into account
Date: Fri, 4 Nov 2011 11:30:10 -0700

On Fri, Nov 4, 2011 at 9:02 AM, Eli Zaretskii <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]