all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
@ 2014-11-26 13:47 Joe Corneli
  2014-11-26 15:55 ` Stefan Monnier
                   ` (3 more replies)
  0 siblings, 4 replies; 35+ messages in thread
From: Joe Corneli @ 2014-11-26 13:47 UTC (permalink / raw)
  To: 19194

Adjusting the font size, I would expect that the window's "body width"
would change -- more characters can be fit into the same amount of
screen space.  Current behaviour does not match this expectation.

M-: (window-body-width) RET  [Note result.]
C-x C--
M-: (window-body-width) RET  [Result is the same.]

The function is described:

"This function returns the width, in columns, of the body of window
window."

If for some reason the "nominal" number of columns needs to calculated
with reference to the default font, then there should be another
function to return the "actual" number of columns.

( I note one practical implication of the underlying issue here:
https://github.com/kiwanami/emacs-calfw/issues/45 )




In GNU Emacs 24.4.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-09-01 on Teacup
Repository revision: 117795 rgm@gnu.org-20140901102126-izlwuvh1vuig41nf
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE XFT ZLIB

Important settings:
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  openwith-mode: t
  show-paren-mode: t
  tooltip-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
<up> <left> D M C-g C-x 1 C-x C-b C-x o <down> <down> 
<down> <return> C-x 1 <up> <C-left> C-s C-w C-w C-w 
C-s C-s C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-l <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> C-e M-x <up> C-g C-M-x 
e C-/ M-x e f d e b u <backspace> <backspace> <backspace> 
<backspace> <backspace> d e b u <tab> d e f <tab> <return> 
M-x <up> <up> <up> <return> n n n n n n n n n n n n 
n n n q <up> <up> <up> <up> <up> <up> M-b <left> <left> 
<left> <up> <up> <up> <up> <up> <C-left> C-r C-w C-w 
C-w C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r <left> <right> C-SPC <C-right> M-w M-x g r 
e p <return> " C-y " SPC * <return> C-x o <down> <down> 
<down> <down> <return> C-e M-b M-b M-f C-h f <return> 
C-x o C-v C-l <up> <up> <up> <up> <up> C-l C-x C-b 
C-x o <down> <down> <down> <down> <down> C-g M-x <up> 
<up> <return> q M-x <up> <return> C-l <C-right> C-e 
C-x C-e M-x <up> <return> M-: <pause> C-y <return> 
M-: <up> <return> C-h v <up> C-e <M-backspace> b o 
d <tab> y C-g C-h f w i n d o w - b o d <tab> w <tab> 
<return> C-x b <return> C-a <right> <right> <right> 
<right> <right> <right> <left> <left> <help-echo> <help-echo> 
<S-down-mouse-1> M-: <up> <return> <S-down-mouse-1> 
M-x <up> <up> <up> <down> <down> C-g M-: <up> <return> 
C-x o M-x r e p o <tab> C-g C-z C-x 1 e m a c s SPC 
- Q <return> M-: <up> C-SPC C-e M-w C-g C-c C-c M-x 
r e p o <tab> r <tab> <return>

Recent messages:
cfw:view-month-calc-param
89 (#o131, #x59, ?Y) [2 times]
Quit
Type "q" to restore previous buffer, M-x scroll-up to scroll help.
89 (#o131, #x59, ?Y)
Quit
89 (#o131, #x59, ?Y)
Making completion list...
Quit [2 times]
Making completion list...

Load-path shadows:
~/mu/mu4e/mu4e-speedbar hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-speedbar
~/mu/mu4e/org-old-mu4e hides /usr/local/share/emacs/site-lisp/mu4e/org-old-mu4e
~/mu/mu4e/mu4e-draft hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-draft
~/mu/mu4e/mu4e-contrib hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-contrib
~/mu/mu4e/mu4e-proc hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-proc
~/mu/mu4e/mu4e-message hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-message
~/mu/mu4e/mu4e-headers hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-headers
~/mu/mu4e/mu4e-meta hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-meta
~/mu/mu4e/mu4e-vars hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-vars
~/mu/mu4e/mu4e-utils hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-utils
~/mu/mu4e/mu4e hides /usr/local/share/emacs/site-lisp/mu4e/mu4e
~/mu/mu4e/mu4e-lists hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-lists
~/mu/mu4e/mu4e-compose hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-compose
~/mu/mu4e/mu4e-main hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-main
~/mu/mu4e/org-mu4e hides /usr/local/share/emacs/site-lisp/mu4e/org-mu4e
~/mu/mu4e/mu4e-view hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-view
~/mu/mu4e/mu4e-about hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-about
~/mu/mu4e/mu4e-mark hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-mark
~/mu/mu4e/mu4e-actions hides /usr/local/share/emacs/site-lisp/mu4e/mu4e-actions
~/org-mode/lisp/org-crypt hides /usr/local/share/emacs/24.4.50/lisp/org/org-crypt
~/org-mode/lisp/org-mouse hides /usr/local/share/emacs/24.4.50/lisp/org/org-mouse
~/org-mode/lisp/ob-R hides /usr/local/share/emacs/24.4.50/lisp/org/ob-R
~/org-mode/lisp/org-indent hides /usr/local/share/emacs/24.4.50/lisp/org/org-indent
~/org-mode/lisp/ob-lilypond hides /usr/local/share/emacs/24.4.50/lisp/org/ob-lilypond
~/org-mode/lisp/org-mobile hides /usr/local/share/emacs/24.4.50/lisp/org/org-mobile
~/org-mode/lisp/ob-scheme hides /usr/local/share/emacs/24.4.50/lisp/org/ob-scheme
~/org-mode/lisp/ob-comint hides /usr/local/share/emacs/24.4.50/lisp/org/ob-comint
~/org-mode/lisp/org-eshell hides /usr/local/share/emacs/24.4.50/lisp/org/org-eshell
~/org-mode/lisp/ob-asymptote hides /usr/local/share/emacs/24.4.50/lisp/org/ob-asymptote
~/org-mode/lisp/ob-makefile hides /usr/local/share/emacs/24.4.50/lisp/org/ob-makefile
~/org-mode/lisp/org-w3m hides /usr/local/share/emacs/24.4.50/lisp/org/org-w3m
~/org-mode/lisp/org-colview hides /usr/local/share/emacs/24.4.50/lisp/org/org-colview
~/org-mode/lisp/org-install hides /usr/local/share/emacs/24.4.50/lisp/org/org-install
~/org-mode/lisp/org-bibtex hides /usr/local/share/emacs/24.4.50/lisp/org/org-bibtex
~/org-mode/lisp/ob-sqlite hides /usr/local/share/emacs/24.4.50/lisp/org/ob-sqlite
~/org-mode/lisp/org-element hides /usr/local/share/emacs/24.4.50/lisp/org/org-element
~/org-mode/lisp/org-timer hides /usr/local/share/emacs/24.4.50/lisp/org/org-timer
~/org-mode/lisp/ob-C hides /usr/local/share/emacs/24.4.50/lisp/org/ob-C
~/org-mode/lisp/ob-haskell hides /usr/local/share/emacs/24.4.50/lisp/org/ob-haskell
~/org-mode/lisp/ob-sql hides /usr/local/share/emacs/24.4.50/lisp/org/ob-sql
~/org-mode/lisp/ob-picolisp hides /usr/local/share/emacs/24.4.50/lisp/org/ob-picolisp
~/org-mode/lisp/ob-java hides /usr/local/share/emacs/24.4.50/lisp/org/ob-java
~/org-mode/lisp/org-footnote hides /usr/local/share/emacs/24.4.50/lisp/org/org-footnote
~/org-mode/lisp/ox-html hides /usr/local/share/emacs/24.4.50/lisp/org/ox-html
~/org-mode/lisp/ob-latex hides /usr/local/share/emacs/24.4.50/lisp/org/ob-latex
~/org-mode/lisp/ob-screen hides /usr/local/share/emacs/24.4.50/lisp/org/ob-screen
~/org-mode/lisp/ob-css hides /usr/local/share/emacs/24.4.50/lisp/org/ob-css
~/org-mode/lisp/org-attach hides /usr/local/share/emacs/24.4.50/lisp/org/org-attach
~/org-mode/lisp/ob-ditaa hides /usr/local/share/emacs/24.4.50/lisp/org/ob-ditaa
~/org-mode/lisp/ob-shen hides /usr/local/share/emacs/24.4.50/lisp/org/ob-shen
~/org-mode/lisp/org-feed hides /usr/local/share/emacs/24.4.50/lisp/org/org-feed
~/org-mode/lisp/ob-keys hides /usr/local/share/emacs/24.4.50/lisp/org/ob-keys
~/org-mode/lisp/ob-exp hides /usr/local/share/emacs/24.4.50/lisp/org/ob-exp
~/org-mode/lisp/org-datetree hides /usr/local/share/emacs/24.4.50/lisp/org/org-datetree
~/org-mode/lisp/org-macs hides /usr/local/share/emacs/24.4.50/lisp/org/org-macs
~/org-mode/lisp/ob-ruby hides /usr/local/share/emacs/24.4.50/lisp/org/ob-ruby
~/org-mode/lisp/ob-mscgen hides /usr/local/share/emacs/24.4.50/lisp/org/ob-mscgen
~/org-mode/lisp/ob-fortran hides /usr/local/share/emacs/24.4.50/lisp/org/ob-fortran
~/org-mode/lisp/org-irc hides /usr/local/share/emacs/24.4.50/lisp/org/org-irc
~/org-mode/lisp/org-version hides /usr/local/share/emacs/24.4.50/lisp/org/org-version
~/org-mode/lisp/ox-beamer hides /usr/local/share/emacs/24.4.50/lisp/org/ox-beamer
~/org-mode/lisp/ob-ref hides /usr/local/share/emacs/24.4.50/lisp/org/ob-ref
~/org-mode/lisp/org-rmail hides /usr/local/share/emacs/24.4.50/lisp/org/org-rmail
~/org-mode/lisp/ox hides /usr/local/share/emacs/24.4.50/lisp/org/ox
~/org-mode/lisp/ob-perl hides /usr/local/share/emacs/24.4.50/lisp/org/ob-perl
~/org-mode/lisp/org-agenda hides /usr/local/share/emacs/24.4.50/lisp/org/org-agenda
~/org-mode/lisp/org-habit hides /usr/local/share/emacs/24.4.50/lisp/org/org-habit
~/org-mode/lisp/org-compat hides /usr/local/share/emacs/24.4.50/lisp/org/org-compat
~/org-mode/lisp/ox-md hides /usr/local/share/emacs/24.4.50/lisp/org/ox-md
~/org-mode/lisp/org-plot hides /usr/local/share/emacs/24.4.50/lisp/org/org-plot
~/org-mode/lisp/ob-clojure hides /usr/local/share/emacs/24.4.50/lisp/org/ob-clojure
~/org-mode/lisp/ob-matlab hides /usr/local/share/emacs/24.4.50/lisp/org/ob-matlab
~/org-mode/lisp/ob-core hides /usr/local/share/emacs/24.4.50/lisp/org/ob-core
~/org-mode/lisp/ob-tangle hides /usr/local/share/emacs/24.4.50/lisp/org/ob-tangle
~/org-mode/lisp/org-loaddefs hides /usr/local/share/emacs/24.4.50/lisp/org/org-loaddefs
~/org-mode/lisp/org-ctags hides /usr/local/share/emacs/24.4.50/lisp/org/org-ctags
~/org-mode/lisp/org-docview hides /usr/local/share/emacs/24.4.50/lisp/org/org-docview
~/org-mode/lisp/ob-ledger hides /usr/local/share/emacs/24.4.50/lisp/org/ob-ledger
~/org-mode/lisp/org hides /usr/local/share/emacs/24.4.50/lisp/org/org
~/org-mode/lisp/org-protocol hides /usr/local/share/emacs/24.4.50/lisp/org/org-protocol
~/org-mode/lisp/ox-latex hides /usr/local/share/emacs/24.4.50/lisp/org/ox-latex
~/org-mode/lisp/ob-gnuplot hides /usr/local/share/emacs/24.4.50/lisp/org/ob-gnuplot
~/org-mode/lisp/ob-sass hides /usr/local/share/emacs/24.4.50/lisp/org/ob-sass
~/org-mode/lisp/org-pcomplete hides /usr/local/share/emacs/24.4.50/lisp/org/org-pcomplete
~/org-mode/lisp/ob hides /usr/local/share/emacs/24.4.50/lisp/org/ob
~/org-mode/lisp/ox-odt hides /usr/local/share/emacs/24.4.50/lisp/org/ox-odt
~/org-mode/lisp/ob-lob hides /usr/local/share/emacs/24.4.50/lisp/org/ob-lob
~/org-mode/lisp/ob-table hides /usr/local/share/emacs/24.4.50/lisp/org/ob-table
~/org-mode/lisp/org-mhe hides /usr/local/share/emacs/24.4.50/lisp/org/org-mhe
~/org-mode/lisp/ob-dot hides /usr/local/share/emacs/24.4.50/lisp/org/ob-dot
~/org-mode/lisp/ob-octave hides /usr/local/share/emacs/24.4.50/lisp/org/ob-octave
~/org-mode/lisp/ob-calc hides /usr/local/share/emacs/24.4.50/lisp/org/ob-calc
~/org-mode/lisp/ob-scala hides /usr/local/share/emacs/24.4.50/lisp/org/ob-scala
~/org-mode/lisp/ox-texinfo hides /usr/local/share/emacs/24.4.50/lisp/org/ox-texinfo
~/org-mode/lisp/org-macro hides /usr/local/share/emacs/24.4.50/lisp/org/org-macro
~/org-mode/lisp/ox-ascii hides /usr/local/share/emacs/24.4.50/lisp/org/ox-ascii
~/org-mode/lisp/ob-org hides /usr/local/share/emacs/24.4.50/lisp/org/ob-org
~/org-mode/lisp/ob-plantuml hides /usr/local/share/emacs/24.4.50/lisp/org/ob-plantuml
~/org-mode/lisp/org-gnus hides /usr/local/share/emacs/24.4.50/lisp/org/org-gnus
~/org-mode/lisp/ox-man hides /usr/local/share/emacs/24.4.50/lisp/org/ox-man
~/org-mode/lisp/ob-emacs-lisp hides /usr/local/share/emacs/24.4.50/lisp/org/ob-emacs-lisp
~/org-mode/lisp/ob-ocaml hides /usr/local/share/emacs/24.4.50/lisp/org/ob-ocaml
~/org-mode/lisp/org-faces hides /usr/local/share/emacs/24.4.50/lisp/org/org-faces
~/org-mode/lisp/org-clock hides /usr/local/share/emacs/24.4.50/lisp/org/org-clock
~/org-mode/lisp/org-src hides /usr/local/share/emacs/24.4.50/lisp/org/org-src
~/org-mode/lisp/ob-lisp hides /usr/local/share/emacs/24.4.50/lisp/org/ob-lisp
~/org-mode/lisp/org-list hides /usr/local/share/emacs/24.4.50/lisp/org/org-list
~/org-mode/lisp/ob-js hides /usr/local/share/emacs/24.4.50/lisp/org/ob-js
~/org-mode/lisp/ob-maxima hides /usr/local/share/emacs/24.4.50/lisp/org/ob-maxima
~/org-mode/lisp/ox-publish hides /usr/local/share/emacs/24.4.50/lisp/org/ox-publish
~/org-mode/lisp/org-archive hides /usr/local/share/emacs/24.4.50/lisp/org/org-archive
~/org-mode/lisp/ob-awk hides /usr/local/share/emacs/24.4.50/lisp/org/ob-awk
~/org-mode/lisp/ob-io hides /usr/local/share/emacs/24.4.50/lisp/org/ob-io
~/org-mode/lisp/ob-python hides /usr/local/share/emacs/24.4.50/lisp/org/ob-python
~/org-mode/lisp/ox-icalendar hides /usr/local/share/emacs/24.4.50/lisp/org/ox-icalendar
~/org-mode/lisp/org-bbdb hides /usr/local/share/emacs/24.4.50/lisp/org/org-bbdb
~/org-mode/lisp/org-id hides /usr/local/share/emacs/24.4.50/lisp/org/org-id
~/org-mode/lisp/org-capture hides /usr/local/share/emacs/24.4.50/lisp/org/org-capture
~/org-mode/lisp/org-entities hides /usr/local/share/emacs/24.4.50/lisp/org/org-entities
~/org-mode/lisp/ox-org hides /usr/local/share/emacs/24.4.50/lisp/org/ox-org
~/org-mode/lisp/org-inlinetask hides /usr/local/share/emacs/24.4.50/lisp/org/org-inlinetask
~/org-mode/lisp/org-info hides /usr/local/share/emacs/24.4.50/lisp/org/org-info
~/org-mode/lisp/ob-eval hides /usr/local/share/emacs/24.4.50/lisp/org/ob-eval
~/org-mode/lisp/org-table hides /usr/local/share/emacs/24.4.50/lisp/org/org-table
~/postdoc.git/elisp/lisp-mode hides /usr/local/share/emacs/24.4.50/lisp/emacs-lisp/lisp-mode

Features:
(shadow emacsbug eieio-opt grep edebug rect cus-edit cus-start cus-load
image-file qp tabify cal-move help-mode cal-china lunar solar cal-dst
cal-bahai cal-islam cal-hebrew diary-lib diary-loaddefs dired-aux vc-git
tex-mode compile latexenc pcmpl-unix ispell misearch multi-isearch
mailalias mail-extr sort face-remap timezone gnutls network-stream
starttls url-http url-gw url-auth url-queue url-cache shr-color
mule-util shell poly-markdown polymode pcase poly-base polymode-weave
polymode-export polymode-methods polymode-classes polymode-common
eieio-custom eieio-base color markdown-mode thingatpt openwith joes-dict
dictem calfw-org org-capture calfw holidays hol-loaddefs htmlize
convenience joes-dired-config ls-lisp joes-buffer-menu-config joes-eww
eww mm-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse url-vars mailcap joes-org-mode
ox-s5 org-agenda ox-latex ox-icalendar ox-html ox-ascii ox-publish ox
org-rmail org-mhe org-irc org-info org-gnus org-docview org-bibtex
bibtex org-bbdb org-w3m gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo parse-time
gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems nnheader wid-edit
org-element avl-tree org-install joes-mu4e-config org-mu4e org org-macro
org-footnote org-pcomplete pcomplete org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval
org-compat org-macs org-loaddefs find-func cal-menu calendar
cal-loaddefs shr smtpmail-multi mu4e mu4e-speedbar speedbar sb-image
ezimage dframe mu4e-main mu4e-view epa derived epg epg-config browse-url
comint ansi-color ring mu4e-headers mu4e-compose mu4e-draft mu4e-actions
ido rfc2368 smtpmail auth-source eieio byte-opt bytecomp byte-compile
cconv eieio-core gnus-util password-cache sendmail mu4e-mark
mu4e-message html2text mu4e-proc mu4e-utils doc-view jka-compr
image-mode mu4e-lists mu4e-about mu4e-vars message cl-macs dired
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 hl-line cl gv mu4e-meta
generic generic-x advice help-fns edmacro kmacro cl-loaddefs cl-lib
paren time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-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 nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process gfilenotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Memory information:
((conses 16 633853 89119)
 (symbols 48 45326 4)
 (miscs 40 4504 2420)
 (strings 32 104101 9049)
 (string-bytes 1 3520659)
 (vectors 16 42195)
 (vector-slots 8 1492748 165381)
 (floats 8 1084 572)
 (intervals 56 12494 1976)
 (buffers 976 67)
 (heap 1024 63592 6821))





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-26 13:47 bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Joe Corneli
@ 2014-11-26 15:55 ` Stefan Monnier
  2014-11-26 16:34   ` Joe Corneli
  2014-11-26 16:04 ` Eli Zaretskii
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2014-11-26 15:55 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

> function to return the "actual" number of columns.

How do you define "actual number of columns" in the presence of
proportional fonts, images, and text of variable size?


        Stefan





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-26 13:47 bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Joe Corneli
  2014-11-26 15:55 ` Stefan Monnier
@ 2014-11-26 16:04 ` Eli Zaretskii
  2014-11-27  9:44 ` martin rudalics
  2022-02-10  8:16 ` bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust Lars Ingebrigtsen
  3 siblings, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-26 16:04 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

> From: Joe Corneli <holtzermann17@gmail.com>
> Date: Wed, 26 Nov 2014 13:47:14 +0000
> 
> Adjusting the font size, I would expect that the window's "body width"
> would change -- more characters can be fit into the same amount of
> screen space.  Current behaviour does not match this expectation.
> 
> M-: (window-body-width) RET  [Note result.]
> C-x C--
> M-: (window-body-width) RET  [Result is the same.]
> 
> The function is described:
> 
> "This function returns the width, in columns, of the body of window
> window."

That's not what it says in Emacs 24.4.  It says this:

  If PIXELWISE is nil, return the largest integer smaller than WINDOW's
  pixel width divided by the character width of WINDOW's frame.

IOW, the function is explicitly documented to measure columns in
canonical character units.  It functions as designed.

> If for some reason the "nominal" number of columns needs to calculated
> with reference to the default font, then there should be another
> function to return the "actual" number of columns.
> 
> ( I note one practical implication of the underlying issue here:
> https://github.com/kiwanami/emacs-calfw/issues/45 )

I've read that, and since I don't know what Calfw is or what it does,
it is hard for me to interpret your use case.  If you explain it in
small words, I'm sure a solution will be found, as Emacs has more than
enough functions to give you the width in any units you want, provided
that they are uniform (i.e., don't expect that to work when teh window
uses variable size fonts).

One simple technique is to measure everything in pixels, but I don't
know at this point whether this will solve your use case.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-26 15:55 ` Stefan Monnier
@ 2014-11-26 16:34   ` Joe Corneli
  2014-11-26 17:06     ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: Joe Corneli @ 2014-11-26 16:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 19194

On Wed, Nov 26 2014, Eli Zaretskii wrote:

> One simple technique is to measure everything in pixels, but I don't
> know at this point whether this will solve your use case.

That would probably do it for me, yes.

On Wed, Nov 26 2014, Stefan Monnier wrote:

>> function to return the "actual" number of columns.
>
> How do you define "actual number of columns" in the presence of
> proportional fonts, images, and text of variable size?

I hadn't considered anything but fixed width fonts with uniform size --
but, for instance, the width could be reported in em-length units.

If people switch fonts mid-line, that's clearly a pain - but "ems" could
be defined relative to point-size-at-point, and would accordingly return
an accurate *length*.  In the general not the same as the "actual number
of columns" - but possibly still of use.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-26 16:34   ` Joe Corneli
@ 2014-11-26 17:06     ` Eli Zaretskii
  0 siblings, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-26 17:06 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

> From: Joe Corneli <holtzermann17@gmail.com>
> Date: Wed, 26 Nov 2014 16:34:21 +0000
> Cc: 19194@debbugs.gnu.org
> 
> If people switch fonts mid-line, that's clearly a pain - but "ems" could
> be defined relative to point-size-at-point, and would accordingly return
> an accurate *length*.

But functions like posn-at-point and other similar functions we have
already report the column number of a given position, so you could use
that as your "column counter".





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-26 13:47 bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Joe Corneli
  2014-11-26 15:55 ` Stefan Monnier
  2014-11-26 16:04 ` Eli Zaretskii
@ 2014-11-27  9:44 ` martin rudalics
  2014-11-27 10:54   ` Joe Corneli
  2014-11-27 16:17   ` Eli Zaretskii
  2022-02-10  8:16 ` bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust Lars Ingebrigtsen
  3 siblings, 2 replies; 35+ messages in thread
From: martin rudalics @ 2014-11-27  9:44 UTC (permalink / raw)
  To: Joe Corneli, 19194

 > Adjusting the font size, I would expect that the window's "body width"
 > would change -- more characters can be fit into the same amount of
 > screen space.  Current behaviour does not match this expectation.
 >
 > M-: (window-body-width) RET  [Note result.]
 > C-x C--
 > M-: (window-body-width) RET  [Result is the same.]
 >
 > The function is described:
 >
 > "This function returns the width, in columns, of the body of window
 > window."
 >
 > If for some reason the "nominal" number of columns needs to calculated
 > with reference to the default font, then there should be another
 > function to return the "actual" number of columns.

The doc-string of `text-scale-adjust' is slightly misleading.

(defun text-scale-adjust (inc)
   "Adjust the height of the default face by INC.

AFAICT this does not change the height of the default face - it affects
how the display engine calculates the height of text when displaying a
buffer current at the time `text-scale-adjust' was called.

I'm not sure whether we want to define the size of a window in terms of
the buffer displayed in that window.  One consequence of such a change
would be that the sum of the total height of two windows might no more
equal the total height of their parent window.

If we did, we'd need a way to conveniently specify a buffer's default
character width/height.  Then we should probably redefine a number of
functions like `shrink-window' or `split-window' to work in terms of
that value.  And maybe specify a mode to control that behavior.

 > ( I note one practical implication of the underlying issue here:
 > https://github.com/kiwanami/emacs-calfw/issues/45 )

If you told me how you get the "adjusted font size", I could tell you
how to scale the value returned by `window-body-width' accordingly.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27  9:44 ` martin rudalics
@ 2014-11-27 10:54   ` Joe Corneli
  2014-11-27 18:35     ` martin rudalics
  2014-11-27 16:17   ` Eli Zaretskii
  1 sibling, 1 reply; 35+ messages in thread
From: Joe Corneli @ 2014-11-27 10:54 UTC (permalink / raw)
  To: martin rudalics; +Cc: 19194

On Thu, Nov 27 2014, martin rudalics wrote:

> I'm not sure whether we want to define the size of a window in terms of
> the buffer displayed in that window.  One consequence of such a change
> would be that the sum of the total height of two windows might no more
> equal the total height of their parent window.

I think you are totally right.  To keep the buffer and window
distinction properly, my note should probably be read as a feature
request, not a bug report.  The request is for a function such as
`buffer-body-width' that would return the width of the current displayed
buffer in em-length units.

> If you told me how you get the "adjusted font size", I could tell you
> how to scale the value returned by `window-body-width' accordingly.

Sounds promising!  I just pressed C-x C-- which runs `text-scale-adjust'
to the effect: "Decrease the default face height by one step".  The step
is `text-scale-mode-step', unchanged from its default value of 1.2.  The
number of steps looks to be stored buffer-locally as
`text-scale-mode-amount'.

... So a candidate function would be:

(defun buffer-body-width (&optional buffer pixelwise)
  (let ((width (window-body-width (get-buffer-window (or buffer
							 (current-buffer)))
				  pixelwise)))
    (floor (cond 
	    ((eq text-scale-mode-amount 0)
	     width)
	    ((> text-scale-mode-amount 0)
	     (/ width (* text-scale-mode-step text-scale-mode-amount)))
	    ((< text-scale-mode-amount 0)
	     (* width (* -1 text-scale-mode-step text-scale-mode-amount)))))))









^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27  9:44 ` martin rudalics
  2014-11-27 10:54   ` Joe Corneli
@ 2014-11-27 16:17   ` Eli Zaretskii
  2014-11-27 18:35     ` martin rudalics
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-27 16:17 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Thu, 27 Nov 2014 10:44:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> (defun text-scale-adjust (inc)
>    "Adjust the height of the default face by INC.
> 
> AFAICT this does not change the height of the default face - it affects
> how the display engine calculates the height of text when displaying a
> buffer current at the time `text-scale-adjust' was called.

No, it works via face remapping, see text-scale-mode.  IOW, it does
change the height of the default face by replacing it with another
face.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 10:54   ` Joe Corneli
@ 2014-11-27 18:35     ` martin rudalics
  2014-11-27 18:52       ` Eli Zaretskii
  2014-11-27 20:23       ` Joe Corneli
  0 siblings, 2 replies; 35+ messages in thread
From: martin rudalics @ 2014-11-27 18:35 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

 > I think you are totally right.  To keep the buffer and window
 > distinction properly, my note should probably be read as a feature
 > request, not a bug report.  The request is for a function such as
 > `buffer-body-width' that would return the width of the current displayed
 > buffer in em-length units.

What is the width of a buffer?  What are em-lenght units?

 > Sounds promising!  I just pressed C-x C-- which runs `text-scale-adjust'
 > to the effect: "Decrease the default face height by one step".

That's incorrect.  The doc-string of `text-scale-decrease' tells it more
accurately: "Decrease the height of the default face in the current
buffer by DEC steps."

 > The step
 > is `text-scale-mode-step', unchanged from its default value of 1.2.  The
 > number of steps looks to be stored buffer-locally as
 > `text-scale-mode-amount'.
 >
 > ... So a candidate function would be:
 >
 > (defun buffer-body-width (&optional buffer pixelwise)
 >    (let ((width (window-body-width (get-buffer-window (or buffer
 > 							 (current-buffer)))
 > 				  pixelwise)))
 >      (floor (cond
 > 	    ((eq text-scale-mode-amount 0)
 > 	     width)
 > 	    ((> text-scale-mode-amount 0)
 > 	     (/ width (* text-scale-mode-step text-scale-mode-amount)))
 > 	    ((< text-scale-mode-amount 0)
 > 	     (* width (* -1 text-scale-mode-step text-scale-mode-amount)))))))

We could start from here.  But:

(1) `text-scale-mode-amount' is not autoloaded, so we get an error
     calling this with emacs -Q.

(2) `text-scale-mode-amount' is buffer-local.  So we have to choose the
     right buffer before evaluating it.

(3) `text-scale-mode-amount' constitutes a request to the display engine
     to scale a face height.  What shall we do when our target machine
     can't display the character with the requested height and uses, for
     example, the nearest available height instead?

(4) I don't know whether and how the frame's `font' parameter can/should
     affect the height of the "default face".  Likely this is not a
     problem - Eli will tell.

As I said before, I'd rather have a buffer-local equivalent of the
variable `frame-char-height', something like `buffer-char-height',
instead of having to find out by myself what the correct value is.

Next we should try to incorporate this in `window-body-height', either
by overloading the PIXELWISE argument - for example, if this is the
symbol `lines-scaled' we'd return the scaled lines - or with an extra
BUFFER argument which would also allow to retrieve the body height of a
window as if it displayed BUFFER or with something better yet ...

As a consequence, we'd probably have to rename the current C routine
`window-body-height' to `window-body-height-internal' and write the new
`window-body-height' in Elisp on top of that.

And finally we would have to do that for all related functions like
`window-total-height', `split-window' or `window-resize' and decide how
a user can specify that, when splitting a window via say C-4 C-x 2, the
top window should have four lines counted in the original window
buffer's text scaling.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 16:17   ` Eli Zaretskii
@ 2014-11-27 18:35     ` martin rudalics
  2014-11-27 18:46       ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-11-27 18:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> AFAICT this does not change the height of the default face - it affects
 >> how the display engine calculates the height of text when displaying a
 >> buffer current at the time `text-scale-adjust' was called.
 >
 > No, it works via face remapping, see text-scale-mode.  IOW, it does
 > change the height of the default face by replacing it with another
 > face.

On a per-buffer basis.  The height of the default face is unaffected
here.  I suppose the display engine applies the scaling lazily, whenever
it has to retrieve the height of the default face.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 18:35     ` martin rudalics
@ 2014-11-27 18:46       ` Eli Zaretskii
  2014-11-27 19:58         ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-27 18:46 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Thu, 27 Nov 2014 19:35:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> AFAICT this does not change the height of the default face - it affects
>  >> how the display engine calculates the height of text when displaying a
>  >> buffer current at the time `text-scale-adjust' was called.
>  >
>  > No, it works via face remapping, see text-scale-mode.  IOW, it does
>  > change the height of the default face by replacing it with another
>  > face.
> 
> On a per-buffer basis.  The height of the default face is unaffected
> here.

We both talk about the "default face", but mean 2 different things, it
seems.  I mean the face that is referenced by 'default'.

> I suppose the display engine applies the scaling lazily, whenever it
> has to retrieve the height of the default face.

The display engine doesn't apply the scaling at all, it just uses the
face and obeys its attributes.  text-scale-mode prepares that face,
like this:

    (face-remap-add-relative 'default
                             :height
                             (expt text-scale-mode-step
                                   text-scale-mode-amount))





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 18:35     ` martin rudalics
@ 2014-11-27 18:52       ` Eli Zaretskii
  2014-11-27 19:58         ` martin rudalics
  2014-11-27 20:23       ` Joe Corneli
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-27 18:52 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Thu, 27 Nov 2014 19:35:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 19194@debbugs.gnu.org
> 
> (4) I don't know whether and how the frame's `font' parameter can/should
>      affect the height of the "default face".  Likely this is not a
>      problem - Eli will tell.

Sorry, I don't understand the question.  In particular, a frame
doesn't have a font; a face does.  Perhaps you are talking about the
font of the frame's 'default' face -- this is what the frame's 'font'
parameter determines, AFAIR.

> As I said before, I'd rather have a buffer-local equivalent of the
> variable `frame-char-height', something like `buffer-char-height',
> instead of having to find out by myself what the correct value is.

You mean, like what default-font-height returns?

> Next we should try to incorporate this in `window-body-height'

You mean, like what window-screen-lines returns?

Btw, the OP wanted the width of the window, not its height, AFAIR.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 18:46       ` Eli Zaretskii
@ 2014-11-27 19:58         ` martin rudalics
  2014-11-27 20:37           ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-11-27 19:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> On a per-buffer basis.  The height of the default face is unaffected
 >> here.
 >
 > We both talk about the "default face", but mean 2 different things, it
 > seems.  I mean the face that is referenced by 'default'.

Hmm... I'm lost.  Which face is referenced by the default face?  From
the manual I only know that "all other faces implicitly inherit from
it".  Probably that's the clue of face remappping ...

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 18:52       ` Eli Zaretskii
@ 2014-11-27 19:58         ` martin rudalics
  2014-11-27 20:43           ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-11-27 19:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> (4) I don't know whether and how the frame's `font' parameter can/should
 >>       affect the height of the "default face".  Likely this is not a
 >>       problem - Eli will tell.
 >
 > Sorry, I don't understand the question.  In particular, a frame
 > doesn't have a font; a face does.

I meant that from section 28.3.3.8 "Font and Color Parameters" of the
Elisp manual:

`font'
      The name of the font for displaying text in the frame.  This is a
      string, either a valid font name for your system or the name of an
      Emacs fontset (*note Fontsets::).  It is equivalent to the `font'
      attribute of the `default' face.

 > Perhaps you are talking about the
 > font of the frame's 'default' face -- this is what the frame's 'font'
 > parameter determines, AFAIR.

Maybe.  The nomenclature is incomprehensible for me.  Could you try to
explain how the height of a character assigned the default face (the one
whose attributes are all specified) can change in dependence of the
frame where the character is displayed?

 > You mean, like what default-font-height returns?

Does this take text scaling into account?  Is this the final value as it
would be displayed or could the height of "the font of the frame's
'default' face" get mixed in afterwards?  And how does
`default-font-height' differ from `default-line-height'?

In any case, somehing like `default-font-width' seems all we need.

 >> Next we should try to incorporate this in `window-body-height'
 >
 > You mean, like what window-screen-lines returns?

This sounds like a good idea as well, but then ...

 > Btw, the OP wanted the width of the window, not its height, AFAIR.

... we would need `window-screen-columns' too.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 18:35     ` martin rudalics
  2014-11-27 18:52       ` Eli Zaretskii
@ 2014-11-27 20:23       ` Joe Corneli
  2014-11-28  7:27         ` martin rudalics
  1 sibling, 1 reply; 35+ messages in thread
From: Joe Corneli @ 2014-11-27 20:23 UTC (permalink / raw)
  To: martin rudalics; +Cc: 19194


On Thu, Nov 27 2014, martin rudalics wrote:

>  > I think you are totally right.  To keep the buffer and window
>  > distinction properly, my note should probably be read as a feature
>  > request, not a bug report.  The request is for a function such as
>  > `buffer-body-width' that would return the width of the current displayed
>  > buffer in em-length units.
>
> What is the width of a buffer?  What are em-lenght units?

I mean, the distance (in useful units!) from the left side of the
buffer, as displayed within a given window, to the right side of that
window.  If the buffer is displayed using *a fixed width font*, then one
useful unit is *columns*, i.e. the number of columns that can be
displayed before line wrap or continuation kicks in.  However, if the
buffer is displayed using a variable-width font, then "columns" is *not*
necessarily a meaningful unit -- as has been pointed out in the earlier
discussion.  In this case, see below for "ems."

To be clear, the width of the *window* calculated in non-buffer-specific
units is not generally "useful" for the purpose of measuring the number
of characters that can be fit, horizontally, into the buffer.
Nevertheless, if the window is displayed using *the default face* at the
default scale (and if the default font happens to be fixed width!) then
`window-body-width' does indeed return the number of columns.

From Wikipedia:

  «An em is a unit in the field of typography, equal to the currently
  specified point size. For example, one em in a 16-point typeface is 16
  points. Therefore, this unit is the same for all typefaces at a given
  point size. [...] The name "em" was originally a reference to the
  width of the the capital "M" in the typeface and size being used,
  which was often the same as the point size.»

> (2) `text-scale-mode-amount' is buffer-local.  So we have to choose the
>      right buffer before evaluating it.

I agree, this is indeed an important.

> (3) `text-scale-mode-amount' constitutes a request to the display engine
>      to scale a face height.  What shall we do when our target machine
>      can't display the character with the requested height and uses, for
>      example, the nearest available height instead?

Presumably the function should fall back to the height (and
corresponding scale factor) that is actually used.  This is an edge case
that I hadn't considered!






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 19:58         ` martin rudalics
@ 2014-11-27 20:37           ` Eli Zaretskii
  2014-11-28  7:27             ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-27 20:37 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Thu, 27 Nov 2014 20:58:24 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> On a per-buffer basis.  The height of the default face is unaffected
>  >> here.
>  >
>  > We both talk about the "default face", but mean 2 different things, it
>  > seems.  I mean the face that is referenced by 'default'.
> 
> Hmm... I'm lost.  Which face is referenced by the default face?

The face whose symbol is 'default', e.g.:

  (face-font 'default)
   => "-outline-Courier New-normal-normal-normal-mono-15-*-*-*-c-*-iso8859-1"





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 19:58         ` martin rudalics
@ 2014-11-27 20:43           ` Eli Zaretskii
  2014-11-28  7:29             ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-27 20:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Thu, 27 Nov 2014 20:58:45 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
> Could you try to explain how the height of a character assigned the
> default face (the one whose attributes are all specified) can change
> in dependence of the frame where the character is displayed?

Faces are frame-specific.  The same face can have different attributes
on each frame, and that includes the size.

>  > You mean, like what default-font-height returns?
> 
> Does this take text scaling into account?

Yes.  You can try it yourself: call it before and after "C-x C-+", and
see for yourself.

> Is this the final value as it would be displayed or could the height
> of "the font of the frame's 'default' face" get mixed in afterwards?

The former, I think.

> And how does `default-font-height' differ from
> `default-line-height'?

default-line-height includes the line-spacing.

>  > Btw, the OP wanted the width of the window, not its height, AFAIR.
> 
> ... we would need `window-screen-columns' too.

That will be harder, unless we change some APIs.  We currently don't
have the font width in what font-info returns.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 20:23       ` Joe Corneli
@ 2014-11-28  7:27         ` martin rudalics
  0 siblings, 0 replies; 35+ messages in thread
From: martin rudalics @ 2014-11-28  7:27 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

 >> What is the width of a buffer?  What are em-lenght units?
 >
 > I mean, the distance (in useful units!) from the left side of the
 > buffer,

... a buffer has no "left side" unless you mean the value of how many
columns the buffer has been scrolled horizontally in some window ...

 > as displayed within a given window, to the right side of that
 > window.  If the buffer is displayed using *a fixed width font*, then one
 > useful unit is *columns*, i.e. the number of columns that can be
 > displayed before line wrap or continuation kicks in.  However, if the
 > buffer is displayed using a variable-width font, then "columns" is *not*
 > necessarily a meaningful unit -- as has been pointed out in the earlier
 > discussion.  In this case, see below for "ems."
 >
 > To be clear, the width of the *window* calculated in non-buffer-specific
 > units is not generally "useful" for the purpose of measuring the number
 > of characters that can be fit, horizontally, into the buffer.

".., into the window" I presume.  Is it that what you want to do: Fit
characters into a window?

 > Nevertheless, if the window is displayed using *the default face* at the
 > default scale (and if the default font happens to be fixed width!) then
 > `window-body-width' does indeed return the number of columns.

The number of columns available for displaying the buffer in the window.

 >    «An em is a unit in the field of typography, equal to the currently
 >    specified point size. For example, one em in a 16-point typeface is 16
 >    points. Therefore, this unit is the same for all typefaces at a given
 >    point size. [...] The name "em" was originally a reference to the
 >    width of the the capital "M" in the typeface and size being used,
 >    which was often the same as the point size.»

So you mean the width of a default face "M" in points here?  No idea how
to get that.  IIRC `nlinum-mode' tries to approximate that somehow.

 >> (3) `text-scale-mode-amount' constitutes a request to the display engine
 >>       to scale a face height.  What shall we do when our target machine
 >>       can't display the character with the requested height and uses, for
 >>       example, the nearest available height instead?
 >
 > Presumably the function should fall back to the height (and
 > corresponding scale factor) that is actually used.  This is an edge case
 > that I hadn't considered!

Apparently it's possible to get the face actually used, but I don't
understand how.

martin






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 20:37           ` Eli Zaretskii
@ 2014-11-28  7:27             ` martin rudalics
  2014-11-28  8:42               ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-11-28  7:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> Hmm... I'm lost.  Which face is referenced by the default face?
 >
 > The face whose symbol is 'default', e.g.:
 >
 >    (face-font 'default)
 >     => "-outline-Courier New-normal-normal-normal-mono-15-*-*-*-c-*-iso8859-1"

But that is a font.  I must be stuck in some biased assumption about
fonts and face.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-27 20:43           ` Eli Zaretskii
@ 2014-11-28  7:29             ` martin rudalics
  2014-11-28  8:49               ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-11-28  7:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 > Faces are frame-specific.  The same face can have different attributes
 > on each frame, and that includes the size.

That's what I'm trying to fathom out here all the time.  So when
calculating the actual height of a character as it will be displayed in
a window I have to apply (in some order) the height attribute specified
by (1) the font of the frame the window belongs to, (2) the font of the
buffer shown in the window, and (3) the font of the default face.

 >>   > You mean, like what default-font-height returns?
 >>
 >> Does this take text scaling into account?
 >
 > Yes.  You can try it yourself: call it before and after "C-x C-+", and
 > see for yourself.

I did now.

 >> Is this the final value as it would be displayed or could the height
 >> of "the font of the frame's 'default' face" get mixed in afterwards?
 >
 > The former, I think.

OK.  Now how do I get the `default-font-width' from that?

 >> And how does `default-font-height' differ from
 >> `default-line-height'?
 >
 > default-line-height includes the line-spacing.

I see.  Silly of me to ask.

The doc-string of this should be slightly improved because OT1H
`line-spacing' is buffer-local and OTOH "the frame" in

   The value includes `line-spacing', if any, defined for the buffer
   or the frame.

is slightly ambiguous.

 >>   > Btw, the OP wanted the width of the window, not its height, AFAIR.
 >>
 >> ... we would need `window-screen-columns' too.
 >
 > That will be harder, unless we change some APIs.  We currently don't
 > have the font width in what font-info returns.

Is there a way to approximate the "width of a character" in points from
(1) its height and (2) its width attribute?

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-28  7:27             ` martin rudalics
@ 2014-11-28  8:42               ` Eli Zaretskii
  0 siblings, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-28  8:42 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Fri, 28 Nov 2014 08:27:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> Hmm... I'm lost.  Which face is referenced by the default face?
>  >
>  > The face whose symbol is 'default', e.g.:
>  >
>  >    (face-font 'default)
>  >     => "-outline-Courier New-normal-normal-normal-mono-15-*-*-*-c-*-iso8859-1"
> 
> But that is a font.

Yes.  I just demonstrated how you can reference that face by the
'default' symbol, that's all.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-28  7:29             ` martin rudalics
@ 2014-11-28  8:49               ` Eli Zaretskii
  2014-11-28 18:38                 ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-28  8:49 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Fri, 28 Nov 2014 08:29:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  > Faces are frame-specific.  The same face can have different attributes
>  > on each frame, and that includes the size.
> 
> That's what I'm trying to fathom out here all the time.  So when
> calculating the actual height of a character as it will be displayed in
> a window I have to apply (in some order) the height attribute specified
> by (1) the font of the frame the window belongs to, (2) the font of the
> buffer shown in the window, and (3) the font of the default face.

We always use the current default face's font for this.  Otherwise,
you get to a problem that IMO is insoluble even in principle.

>  >> Is this the final value as it would be displayed or could the height
>  >> of "the font of the frame's 'default' face" get mixed in afterwards?
>  >
>  > The former, I think.
> 
> OK.  Now how do I get the `default-font-width' from that?

You need help from Emacs, because it knows everything about that
font's metrics.  But we don't have an API for that for now.

>  > default-line-height includes the line-spacing.
> 
> I see.  Silly of me to ask.
> 
> The doc-string of this should be slightly improved because OT1H
> `line-spacing' is buffer-local and OTOH "the frame" in
> 
>    The value includes `line-spacing', if any, defined for the buffer
>    or the frame.
> 
> is slightly ambiguous.

It's ambiguous on purpose: the line-spacing can be specified in
several ways.  Feel free to improve the doc string.

>  >>   > Btw, the OP wanted the width of the window, not its height, AFAIR.
>  >>
>  >> ... we would need `window-screen-columns' too.
>  >
>  > That will be harder, unless we change some APIs.  We currently don't
>  > have the font width in what font-info returns.
> 
> Is there a way to approximate the "width of a character" in points from
> (1) its height and (2) its width attribute?

There's no need: the width of a font is well defined, and the display
engine uses it all the time.  We just don't expose it in the font-info
API; we should add that.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-28  8:49               ` Eli Zaretskii
@ 2014-11-28 18:38                 ` martin rudalics
  2014-11-28 19:20                   ` Eli Zaretskii
  2014-12-19 19:40                   ` Eli Zaretskii
  0 siblings, 2 replies; 35+ messages in thread
From: martin rudalics @ 2014-11-28 18:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> That's what I'm trying to fathom out here all the time.  So when
 >> calculating the actual height of a character as it will be displayed in
 >> a window I have to apply (in some order) the height attribute specified
 >> by (1) the font of the frame the window belongs to, (2) the font of the
 >> buffer shown in the window, and (3) the font of the default face.
 >
 > We always use the current default face's font for this.  Otherwise,
 > you get to a problem that IMO is insoluble even in principle.

But doesn't that imply that `frame-char-height' is just an artifact?

 >> OK.  Now how do I get the `default-font-width' from that?
 >
 > You need help from Emacs, because it knows everything about that
 > font's metrics.  But we don't have an API for that for now.

I see.  Can you provide one?

Thanks, martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-28 18:38                 ` martin rudalics
@ 2014-11-28 19:20                   ` Eli Zaretskii
  2014-12-19 19:40                   ` Eli Zaretskii
  1 sibling, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2014-11-28 19:20 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Fri, 28 Nov 2014 19:38:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> That's what I'm trying to fathom out here all the time.  So when
>  >> calculating the actual height of a character as it will be displayed in
>  >> a window I have to apply (in some order) the height attribute specified
>  >> by (1) the font of the frame the window belongs to, (2) the font of the
>  >> buffer shown in the window, and (3) the font of the default face.
>  >
>  > We always use the current default face's font for this.  Otherwise,
>  > you get to a problem that IMO is insoluble even in principle.
> 
> But doesn't that imply that `frame-char-height' is just an artifact?

It's useful for dealing with measures in canonical character units.

>  >> OK.  Now how do I get the `default-font-width' from that?
>  >
>  > You need help from Emacs, because it knows everything about that
>  > font's metrics.  But we don't have an API for that for now.
> 
> I see.  Can you provide one?

Added to my todo.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-11-28 18:38                 ` martin rudalics
  2014-11-28 19:20                   ` Eli Zaretskii
@ 2014-12-19 19:40                   ` Eli Zaretskii
  2014-12-20 10:10                     ` martin rudalics
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-12-19 19:40 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Fri, 28 Nov 2014 19:38:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> OK.  Now how do I get the `default-font-width' from that?
>  >
>  > You need help from Emacs, because it knows everything about that
>  > font's metrics.  But we don't have an API for that for now.
> 
> I see.  Can you provide one?

Now done on trunk.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-19 19:40                   ` Eli Zaretskii
@ 2014-12-20 10:10                     ` martin rudalics
  2014-12-20 11:52                       ` Joe Corneli
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-12-20 10:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 > Now done on trunk.

Thank you.

Mr. Corneli: How about a doc-string that goes as follows?


(window-body-width &optional WINDOW PIXELWISE)

Return the width of WINDOW's text area.

WINDOW must be a live window and defaults to the selected one.  The
return value does not include any vertical dividers, fringes or marginal
areas, or scroll bars.

If the optional argument PIXELWISE is nil, return the largest integer
smaller than WINDOW's pixel width divided by the character width of
WINDOW's frame.  If PIXELWISE is the symbol `window', return the largest
integer smaller than WINDOW's pixel width divided by the character width
of WINDOW.  In either of these cases, if a column at the right of the
text area is only partially visible, that column is not counted.

PIXELWISE t means return the exact width of the text area in pixels.
Other values of PIXELWISE are reserved for future use.


martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 10:10                     ` martin rudalics
@ 2014-12-20 11:52                       ` Joe Corneli
  2014-12-20 14:49                         ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Joe Corneli @ 2014-12-20 11:52 UTC (permalink / raw)
  To: martin rudalics; +Cc: 19194


On Sat, Dec 20 2014, martin rudalics wrote:

>  > Now done on trunk.
>
> Thank you.
>
> Mr. Corneli: How about a doc-string that goes as follows?

The one thing I'd add is an explanation of how "character width" is
found or computed for variable-width fonts.  (E.g. is it the width of an
"M"?)

> If the optional argument PIXELWISE is nil, return the largest integer
> smaller than WINDOW's pixel width divided by the character width of
> WINDOW's frame.  If PIXELWISE is the symbol `window', return the largest
> integer smaller than WINDOW's pixel width divided by the character width
> of WINDOW.  In either of these cases, if a column at the right of the
> text area is only partially visible, that column is not counted.
>
> PIXELWISE t means return the exact width of the text area in pixels.
> Other values of PIXELWISE are reserved for future use.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 11:52                       ` Joe Corneli
@ 2014-12-20 14:49                         ` martin rudalics
  2014-12-20 16:18                           ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-12-20 14:49 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 19194

 > The one thing I'd add is an explanation of how "character width" is
 > found or computed for variable-width fonts.  (E.g. is it the width of an
 > "M"?)

Elsewhere I proposed:

(defun window-char-width (&optional window)
   "Return default character width for WINDOW.
WINDOW must be a live window and defaults to the selected one."
   (setq window (window-normalize-window window t))
   (with-current-buffer (window-buffer window)
     (let* ((info (font-info (face-font 'default)))
        (width (aref info 11)))
       (if (> width 0)
       width
     (aref info 10)))))

You could try to experiment with this and either use

(width (aref info 10))

or

(width (aref info 7))

instead of (aref info 11).  Or use something like

(face-font 'default ?M) instead of (face-font 'default).

I use variable width fonts only in customization buffers, so I'm not
very qualified at checking this myself.  We can use whatever you find
here provided we can pack it into an argument of `window-body-width'.

And Eli certainly knows better, so wait.  Maybe my idea is silly.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 14:49                         ` martin rudalics
@ 2014-12-20 16:18                           ` Eli Zaretskii
  2014-12-20 16:31                             ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-12-20 16:18 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Sat, 20 Dec 2014 15:49:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 19194@debbugs.gnu.org
> 
>  > The one thing I'd add is an explanation of how "character width" is
>  > found or computed for variable-width fonts.  (E.g. is it the width of an
>  > "M"?)
> 
> Elsewhere I proposed:
> 
> (defun window-char-width (&optional window)
>    "Return default character width for WINDOW.
> WINDOW must be a live window and defaults to the selected one."
>    (setq window (window-normalize-window window t))
>    (with-current-buffer (window-buffer window)
>      (let* ((info (font-info (face-font 'default)))
>         (width (aref info 11)))
>        (if (> width 0)
>        width
>      (aref info 10)))))
> 
> You could try to experiment with this and either use
> 
> (width (aref info 10))
> 
> or
> 
> (width (aref info 7))
> 
> instead of (aref info 11).  Or use something like
> 
> (face-font 'default ?M) instead of (face-font 'default).
> 
> I use variable width fonts only in customization buffers, so I'm not
> very qualified at checking this myself.  We can use whatever you find
> here provided we can pack it into an argument of `window-body-width'.
> 
> And Eli certainly knows better, so wait.  Maybe my idea is silly.

I actually don't really understand the question.  What does "character
width" mean when each character has a different width?  Do you (Joe)
mean you want to know the actual width of each and every character?
If so, what for?

In any case, if you do need the width of individual characters, take a
look at font-get-glyphs (and font-at to get you the font for that).





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 16:18                           ` Eli Zaretskii
@ 2014-12-20 16:31                             ` martin rudalics
  2014-12-20 16:47                               ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-12-20 16:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 > I actually don't really understand the question.  What does "character
 > width" mean when each character has a different width?  Do you (Joe)
 > mean you want to know the actual width of each and every character?

The maximum character width.  That's why he proposes to use the width of
an "M" for this.

 > If so, what for?

Probably to know how many characters fit into a line.  With a
proportional font.

 > In any case, if you do need the width of individual characters, take a
 > look at font-get-glyphs (and font-at to get you the font for that).

He wants the width of a default font "M" (where the default fount could
be proportional) filtered by the frame it appears on and the remapping
specified for the buffer the character appears in.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 16:31                             ` martin rudalics
@ 2014-12-20 16:47                               ` Eli Zaretskii
  2014-12-20 17:51                                 ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2014-12-20 16:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Sat, 20 Dec 2014 17:31:34 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  > I actually don't really understand the question.  What does "character
>  > width" mean when each character has a different width?  Do you (Joe)
>  > mean you want to know the actual width of each and every character?
> 
> The maximum character width.  That's why he proposes to use the width of
> an "M" for this.
> 
>  > If so, what for?
> 
> Probably to know how many characters fit into a line.  With a
> proportional font.

But for a proportional font, that question has no meaningful answer.
Using the maximum width could yield a result that it a gross
underestimation.  I fail to see how this could be more useful than
using the average width.

>  > In any case, if you do need the width of individual characters, take a
>  > look at font-get-glyphs (and font-at to get you the font for that).
> 
> He wants the width of a default font "M" (where the default fount could
> be proportional) filtered by the frame it appears on and the remapping
> specified for the buffer the character appears in.

Once you get the font used by a face on that frame and buffer, the
font parameters are fixed.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 16:47                               ` Eli Zaretskii
@ 2014-12-20 17:51                                 ` martin rudalics
  2014-12-20 18:29                                   ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2014-12-20 17:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: holtzermann17, 19194

 >> Probably to know how many characters fit into a line.  With a
 >> proportional font.
 >
 > But for a proportional font, that question has no meaningful answer.
 > Using the maximum width could yield a result that it a gross
 > underestimation.  I fail to see how this could be more useful than
 > using the average width.

Are we sure that all numbers fit into the average width.  If not, we can
get problems with line numbers.

BTW you probably might want to close bugs 1255, 8379 and 10960 now ;-)

 >> He wants the width of a default font "M" (where the default fount could
 >> be proportional) filtered by the frame it appears on and the remapping
 >> specified for the buffer the character appears in.
 >
 > Once you get the font used by a face on that frame and buffer, the
 > font parameters are fixed.

I lost you here.  Does that mean that with proportional fonts an "M" and
an "I" have different fonts?

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes
  2014-12-20 17:51                                 ` martin rudalics
@ 2014-12-20 18:29                                   ` Eli Zaretskii
  0 siblings, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2014-12-20 18:29 UTC (permalink / raw)
  To: martin rudalics; +Cc: holtzermann17, 19194

> Date: Sat, 20 Dec 2014 18:51:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: holtzermann17@gmail.com, 19194@debbugs.gnu.org
> 
>  >> Probably to know how many characters fit into a line.  With a
>  >> proportional font.
>  >
>  > But for a proportional font, that question has no meaningful answer.
>  > Using the maximum width could yield a result that it a gross
>  > underestimation.  I fail to see how this could be more useful than
>  > using the average width.
> 
> Are we sure that all numbers fit into the average width.  If not, we can
> get problems with line numbers.

Like I said: you will get a wrong answer either way.  I think this is
simply the wrong way to do it.  I cannot suggest a better way without
knowing more about the particular application.

> BTW you probably might want to close bugs 1255, 8379 and 10960 now ;-)

So can you ;-)

>  >> He wants the width of a default font "M" (where the default fount could
>  >> be proportional) filtered by the frame it appears on and the remapping
>  >> specified for the buffer the character appears in.
>  >
>  > Once you get the font used by a face on that frame and buffer, the
>  > font parameters are fixed.
> 
> I lost you here.  Does that mean that with proportional fonts an "M" and
> an "I" have different fonts?

I'm saying that specifying the font by a face on a frame makes any
"filtering" redundant.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust
  2014-11-26 13:47 bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Joe Corneli
                   ` (2 preceding siblings ...)
  2014-11-27  9:44 ` martin rudalics
@ 2022-02-10  8:16 ` Lars Ingebrigtsen
  2022-02-10 17:39   ` bug#19194: [External] : " Drew Adams
  3 siblings, 1 reply; 35+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-10  8:16 UTC (permalink / raw)
  To: Joe Corneli; +Cc: 20022, 19194

Joe Corneli <holtzermann17@gmail.com> writes:

> Adjusting the font size, I would expect that the window's "body width"
> would change -- more characters can be fit into the same amount of
> screen space.  Current behaviour does not match this expectation.
>
> M-: (window-body-width) RET  [Note result.]
> C-x C--
> M-: (window-body-width) RET  [Result is the same.]
>
> The function is described:
>
> "This function returns the width, in columns, of the body of window
> window."
>
> If for some reason the "nominal" number of columns needs to calculated
> with reference to the default font, then there should be another
> function to return the "actual" number of columns.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Skimming this thread, I think the conclusion here is that these
functions work as designed.  `C-x C--' reduces the size of the font in
the current buffer, but the "window body width" concept remains the
same.  (I.e., if you create a new buffer and display it, that's what
`window-body-width' is telling you the number of columns for.)

So I don't think there's anything to do here, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#19194: [External] : bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust
  2022-02-10  8:16 ` bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust Lars Ingebrigtsen
@ 2022-02-10 17:39   ` Drew Adams
  0 siblings, 0 replies; 35+ messages in thread
From: Drew Adams @ 2022-02-10 17:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Joe Corneli
  Cc: 20022@debbugs.gnu.org, 19194@debbugs.gnu.org

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

> > Adjusting the font size, I would expect that the window's "body width"
> > would change -- more characters can be fit into the same amount of
> > screen space.  Current behaviour does not match this expectation.
> >
> > M-: (window-body-width) RET  [Note result.]
> > C-x C--
> > M-: (window-body-width) RET  [Result is the same.]
> >
> > The function is described:
> >
> > "This function returns the width, in columns, of the body of window
> > window."
> >
> > If for some reason the "nominal" number of columns needs to calculated
> > with reference to the default font, then there should be another
> > function to return the "actual" number of columns.
> 
> Skimming this thread, I think the conclusion here is that these
> functions work as designed.  `C-x C--' reduces the size of the font in
> the current buffer, but the "window body width" concept remains the
> same.  (I.e., if you create a new buffer and display it, that's what
> `window-body-width' is telling you the number of columns for.)
> 
> So I don't think there's anything to do here, and I'm closing this bug
> report.

The functions work as designed, yes.  But the design
could be improved.

You can decide whether this comment is relevant to
this bug report.  I think it's related, but it's not
exactly the same suggestion/problem.

I've proposed an enhancement to optionally resize
the window to fit the newly displayed text -
shrinking the text shrinks the window etc.  This
enhancement can free up frame or screen real estate
for other windows or frames.

This is not the same as the enhancement hinted at
in this bug report, which I guess is instead to
reflow the text to accommodate/fill the space
provided by the changed text size.  That makes
sense especially if `visual-line-mode' is used.
The enhancement I describe makes sense especially
if that mode is not used.

I've suggested my enhancement before, but it was
rejected, even though it's behavior change is
optional.  I describe it again here, FWIW.

I provide the enhancement in the tiny bit of code
that is library `face-remap+.el' (attached).  It
provides a user option, `text-scale-resize-window',
and it redefines `text-scale-increase' to respect
that option.  A patch is trivial.

[-- Attachment #2: face-remap+.el --]
[-- Type: application/octet-stream, Size: 8034 bytes --]

;;; face-remap+.el --- Extensions to standard library `face-remap.el'.
;;
;; Filename: face-remap+.el
;; Description: Extensions to standard library `face-remap.el'.
;; Author: Drew Adams
;; Maintainer: Drew Adams (concat "drew.adams" "@" "oracle" ".com")
;; Copyright (C) 2009-2018, Drew Adams, all rights reserved.
;; Created: Wed Jun 17 14:26:21 2009 (-0700)
;; Version: 0
;; Package-Requires: ()
;; Last-Updated: Mon Jan  1 11:18:18 2018 (-0800)
;;           By: dradams
;;     Update #: 179
;; URL: https://www.emacswiki.org/emacs/download/face-remap%2b.el
;; Doc URL: https://emacswiki.org/emacs/SetFonts
;; Keywords: window frame face font
;; Compatibility: GNU Emacs: 23.x, 24.x, 25.x, 26.x
;;
;; Features that might be required by this library:
;;
;;   `face-remap'.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;;
;;  Commands `text-scale-decrease', `text-scale-increase', and
;;  `text-scale-adjust' (bound to `C-x C--', `C-x C-+', `C-x C-=', and
;;  `C-x C-0') let you resize the text in the current buffer by
;;  changing its scale factor.  When you shrink or enlarge the
;;  apparent text size this way, however, the window takes no notice
;;  of it.  In particular, although shrinking text can result in extra
;;  horizontal space at the right, window commands do not see this
;;  space as extra.
;;
;;  With this library, user option `text-scale-resize-window' lets you
;;  automatically resize the selected window (horizontally,
;;  vertically, or both) when text is resized, so that the way the
;;  window fits the buffer text remains relatively constant.
;;  Shrinking the text in one window shrinks that window, giving more
;;  space to adjacent windows.
;;
;;  If you also use library `fit-frame.el', then one-window frames
;;  also respond to text resizing by scaling.  If not, then the
;;  text-scale commands have no effect on frame size for one-window
;;  frames.
;;
;;  See also:
;;
;;  * Library `zoom-frm.el', which provides commands `zoom-in' and
;;    `zoom-out', which let you zoom the text in a buffer (as in text
;;    scaling) or the text in an frame.  In the latter case, the
;;    default font of the frame is enlarged or shrunk dynamically.
;;
;;  * Library `doremi-frm.el', which provides commands
;;    `doremi-buffer-font-size+' and `doremi-frame-font-size+', which
;;    provide another way to zoom incrementally.
;;
;;  To use library `face-remap+.el', put it in your `load-path' and
;;  put this sexp in your init file (~/.emacs):
;;
;;   (require 'face-remap+)
;;
;;
;;  Options (user variables) defined here:
;;
;;    `text-scale-resize-window'.
;;
;;
;;  ***** NOTE: The following standard functions defined in `face-remap.el'
;;              have been REDEFINED HERE:
;;
;;    `text-scale-increase' -- Possibly resize the window or frame.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change Log:
;;
;; 2009/06/22 dadams
;;     Removed vestigial defvar (unused variable).
;; 2009/06/17 dadams
;;     Created.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 3, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

(require 'face-remap)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;###autoload
(defcustom text-scale-resize-window t
  "*Non-nil means text scaling resizes the window or frame accordingly.
For example, if you use `C-x C--' (`text-scale-decrease')' to make the
text smaller, then the window or frame is made smaller by a similar
factor.

If the window is not alone in its frame, then the window is resized.
Otherwise, the frame is resized (provided you also use library
`fit-frame.el').  The frame is always resized both horizontally and
vertically."
  :type '(choice
          (const :tag "Do not resize window when scale text"  nil)
          (const :tag "Resize window when scale text"         t)
          (const :tag "Resize only horizontally"              horizontally)
          (const :tag "Resize only vertically"                vertically))
  :group 'display)


;; REPLACES ORIGINAL `text-scale-increase' defined in `face-remap.el',
;;
;; Resize window or frame if `text-scale-resize-window' is non-nil.
;;
;;;###autoload
(defun text-scale-increase (inc)
  "Increase the height of the default face in the current buffer by INC steps.
If the new height is other than the default, `text-scale-mode' is enabled.

Each step scales the height of the default face by the variable
`text-scale-mode-step' (a negative number of steps decreases the
height by the same amount).  As a special case, an argument of 0
removes any scaling currently active.

If option `text-scale-resize-window' is non-nil, then the selected
window or frame is resized accordingly, so as to keep roughly the same
text visible in the window.  Normally, it is the window that is
resized, but if the window is alone in its frame (and if you use
library `fit-frame.el'), then the frame is resized instead.

See option `text-scale-resize-window' for the possible behaviors."
  (interactive "p")
  (let* ((oamount       (if text-scale-mode text-scale-mode-amount 0))
         (scale-factor  (expt text-scale-mode-step (if (= inc 0) (- oamount) inc)))
         (use-frame-p   (and (fboundp 'fit-frame) (one-window-p 'nomini)))
         (edges         (if use-frame-p (window-inside-edges) (window-edges)))
         (owidth        (- (nth 2 edges) (nth 0 edges)))
         ;; If resizing frame, don't count header line offset (Top) - just use Bottom.
         (oheight       (- (nth 3 edges) (if use-frame-p 0 (nth 1 edges)))))
    (setq text-scale-mode-amount
          (if (= inc 0) 0 (+ (if text-scale-mode text-scale-mode-amount 0) inc)))
    (text-scale-mode (if (zerop text-scale-mode-amount) -1 1))
    (when text-scale-resize-window
      (if use-frame-p
          (let* ((width           (round (* owidth  scale-factor)))
                 (height          (round (* oheight scale-factor)))
                 (fparams         (frame-parameters))
                 (tool-bar-lines  (or (cdr (assq 'tool-bar-lines fparams)) 0))
                 (menu-bar-lines  (or (cdr (assq 'menu-bar-lines fparams)) 0))
                 ;; `window-line-height' doesn't seem to work - I filed Emacs bug #3602.
                 (header-line     (window-line-height 'header-line)))
            ;; `set-frame-size' includes frame's menu-bar, tool-bar, and minibuffer.
            (when (cdr (assq 'modeline  fparams)) (setq height  (1+ height)))
            (when (cdr (assq 'minibuffer fparams)) (setq height  (1+ height)))
            (when header-line (setq height (+ height 1)))
            (setq height  (+ height tool-bar-lines menu-bar-lines))
            (fit-frame nil width height))
        (unless (eq text-scale-resize-window 'vertically)
          (condition-case nil
              (enlarge-window-horizontally (round (- (* owidth scale-factor) owidth)))
            (error nil)))
        (unless (eq text-scale-resize-window 'horizontally)
          (condition-case nil
              (enlarge-window (round (- (* oheight scale-factor) oheight)))
            (error nil)))))))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(provide 'face-remap+)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; face-remap+.el ends here

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2022-02-10 17:39 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-26 13:47 bug#19194: 24.4.50; `window-body-width' is not dynamic relative to font size changes Joe Corneli
2014-11-26 15:55 ` Stefan Monnier
2014-11-26 16:34   ` Joe Corneli
2014-11-26 17:06     ` Eli Zaretskii
2014-11-26 16:04 ` Eli Zaretskii
2014-11-27  9:44 ` martin rudalics
2014-11-27 10:54   ` Joe Corneli
2014-11-27 18:35     ` martin rudalics
2014-11-27 18:52       ` Eli Zaretskii
2014-11-27 19:58         ` martin rudalics
2014-11-27 20:43           ` Eli Zaretskii
2014-11-28  7:29             ` martin rudalics
2014-11-28  8:49               ` Eli Zaretskii
2014-11-28 18:38                 ` martin rudalics
2014-11-28 19:20                   ` Eli Zaretskii
2014-12-19 19:40                   ` Eli Zaretskii
2014-12-20 10:10                     ` martin rudalics
2014-12-20 11:52                       ` Joe Corneli
2014-12-20 14:49                         ` martin rudalics
2014-12-20 16:18                           ` Eli Zaretskii
2014-12-20 16:31                             ` martin rudalics
2014-12-20 16:47                               ` Eli Zaretskii
2014-12-20 17:51                                 ` martin rudalics
2014-12-20 18:29                                   ` Eli Zaretskii
2014-11-27 20:23       ` Joe Corneli
2014-11-28  7:27         ` martin rudalics
2014-11-27 16:17   ` Eli Zaretskii
2014-11-27 18:35     ` martin rudalics
2014-11-27 18:46       ` Eli Zaretskii
2014-11-27 19:58         ` martin rudalics
2014-11-27 20:37           ` Eli Zaretskii
2014-11-28  7:27             ` martin rudalics
2014-11-28  8:42               ` Eli Zaretskii
2022-02-10  8:16 ` bug#19194: bug#20022: 24.4.90; window-body-height, window-body-width wrong value after text-scale-adjust Lars Ingebrigtsen
2022-02-10 17:39   ` bug#19194: [External] : " Drew Adams

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.