GNU bug report logs -
#9949
24.0.91; window-width function does not take text-scale-mode-amount into account
Previous Next
Reported by: Josh <josh <at> foxtail.org>
Date: Fri, 4 Nov 2011 02:44:02 UTC
Severity: normal
Merged with 13073
Found in version 24.0.91
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#9949: 24.0.91; window-width function does not take text-scale-mode-amount into account
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 9949 <at> debbugs.gnu.org.
--
9949: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9949
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> From: Josh <josh <at> foxtail.org>
> Date: Fri, 4 Nov 2011 11:30:10 -0700
> Cc: 9949 <at> 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.
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
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)
[Message part 5 (text/html, inline)]
This bug report was last modified 12 years and 221 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.