From: Josh <josh@foxtail.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 9949@debbugs.gnu.org
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 [thread overview]
Message-ID: <CANdFEAHbtU3FUqfdmRbX9+2EwU8ZP6vghWybOS+rN-SwdDdR7Q@mail.gmail.com> (raw)
In-Reply-To: <83ipmzlvu3.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 4330 bytes --]
next prev parent reply other threads:[~2011-11-04 18:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-04 2:29 bug#9949: 24.0.91; window-width function does not take text-scale-mode-amount into account Josh
2011-11-04 10:25 ` Eli Zaretskii
[not found] ` <CANdFEAF10Lkp3VXe-aLa2nQi6BJWzDQiVdY9m3-uYAQxxWBqMA@mail.gmail.com>
2011-11-04 16:02 ` Eli Zaretskii
2011-11-04 18:30 ` Josh [this message]
2011-11-04 19:58 ` martin rudalics
2011-11-04 20:12 ` Eli Zaretskii
2011-11-04 13:56 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANdFEAHbtU3FUqfdmRbX9+2EwU8ZP6vghWybOS+rN-SwdDdR7Q@mail.gmail.com \
--to=josh@foxtail.org \
--cc=9949@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.