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

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

[Josh]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

The window-width function does not take text scale adjustments
into account.  This breaks code such as
http://www.emacswiki.org/emacs/ErcFilling#toc2 which is meant to
insert timestamps aligned to the right edge of the window.

To reproduce starting from emacs -Q,
1) M-: (window-width) RET  ; returns 80 here
2) C-x C-=                 ; window is now 70 characters wide
3) M-: (window-width) RET  ; still returns 80



In GNU Emacs 24.0.91.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
 of 2011-10-30 on virtualmac.porkrind.org
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--host=x86_64-apple-darwin'
'--build=i686-apple-darwin' '--with-ns' 'build_alias=i686-apple-darwin'
'host_alias=x86_64-apple-darwin' 'CC=gcc -mmacosx-version-min=10.5''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.US-ASCII
  value of $XMODIFIERS: nil
  locale-coding-system: us-ascii-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  text-scale-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x e m a c s - v e r <tab> <return> C-x 3 M-: ( w
i n d o w - w i d t h ) <return> C-x C-= C-x C-= M-:
<up> <return> C-x 1 M-x r e p o r t - e m <tab> <r
eturn>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
GNU Emacs 24.0.91.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of
2011-10-30 on virtualmac.porkrind.org
37 (#o45, #x25)
37 (#o45, #x25)

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug face-remap time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

[-- Attachment #2: Type: text/html, Size: 3972 bytes --]

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

[Eli Zaretskii]

> From: Josh <josh@foxtail.org>
> Date: Thu, 3 Nov 2011 19:29:40 -0700
> 
> The window-width function does not take text scale adjustments
> into account.  This breaks code such as
> http://www.emacswiki.org/emacs/ErcFilling#toc2 which is meant to
> insert timestamps aligned to the right edge of the window.
> 
> To reproduce starting from emacs -Q,
> 1) M-: (window-width) RET  ; returns 80 here
> 2) C-x C-=                 ; window is now 70 characters wide
> 3) M-: (window-width) RET  ; still returns 80

This is a problem with imprecise documentation and incorrect
expectations that are caused by that.  window-width and window-height
report the window dimensions in frame's canonical units, i.e. for the
frame's default face.  Changing the font size does not, therefore,
affect the values they return.  AFAICS, this has been so since about
forever.

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').

I've updated the doc strings and the ELisp manual with this caveat and
committed that as trunk revision 106283.

If you are satisfied with this resolution, I will close the bug
report.  If not, then I think this should at best be tagged as
"wishlist", and it should request a different set of functions to
return the values you expected (because window-width and window-height
are used too widely to be able to sustain such a significant change in
functionality).

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.

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

[Eli Zaretskii]

[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?

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

[Josh]

[-- 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 --]

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

[martin rudalics]

 > 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.

You really should leave this job to the display-engine.  Doing your
calculations based on window-width means you'd have to add a function to
`window-configuration-change-hook' and/or `window-size-change-functions'
and recalculate the position of your stamps when a window changes size.
Moreover, a solution based on window-width will fail when you display
the same buffer in two windows of different width.  And another benefit
of using :align-to would be the additional experience whether it does
its job as expected.

martin

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

[Eli Zaretskii]

> From: Josh <josh@foxtail.org>
> Date: Fri, 4 Nov 2011 11:30:10 -0700
> Cc: 9949@debbugs.gnu.org
> 
> > > (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.

I suggest to ask for advice on help-gnu-emacs or emacs-devel, then.

> > 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.

Feel free to file a feature-request bug about that.

I'm closing this one.

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

[martin rudalics]

 > The window-width function does not take text scale adjustments
 > into account.  This breaks code such as
 > http://www.emacswiki.org/emacs/ErcFilling#toc2 which is meant to
 > insert timestamps aligned to the right edge of the window.

Recipe by courtesy of Johan Bockgård:

(insert (propertize
              " " 'display
              '(space :align-to (- text 8))) "#123456")

martin