* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
@ 2017-08-27 5:40 Steve Purcell
2017-08-27 9:15 ` Stephen Berman
2017-08-27 14:32 ` Eli Zaretskii
0 siblings, 2 replies; 17+ messages in thread
From: Steve Purcell @ 2017-08-27 5:40 UTC (permalink / raw)
To: 28248
When display-line-numbers mode is enabled, this has no effect on the
return value of window-width or window-text-width, and there is also no
variable which contains the current width of the line numbers. This all
means there is no way to determine the width of the text area of the
window.
This concretely matters to me because my package "page-break-lines"
remaps the display table of ^L to a horizontal line the width of the
window: this technique is based on prior art.
I note that turning off fringes *does* correctly adjust
window-text-width, so it seems that display-line-numbers-mode should do
the same.
(PS. nice work on the functionality itself!)
In GNU Emacs 26.0.50 (build 1, x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29))
of 2017-08-26 built on Tulku.local
Repository revision: fca62645b6dab55fb39dbef2a09d5044dcf8efc1
Windowing system distributor 'Apple', version 10.3.1504
Recent messages:
Configured features:
JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS MODULES
Important settings:
value of $LC_CTYPE: en_US.UTF-8
value of $LANG: en_US
locale-coding-system: utf-8
Major mode: ELisp
Minor modes in effect:
default-text-scale-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
recentf-mode: t
ivy-historian-mode: t
historian-mode: t
company-quickhelp-mode: t
company-quickhelp-local-mode: t
winner-mode: t
elisp-slime-nav-mode: t
redshank-mode: t
aggressive-indent-mode: t
highlight-quoted-mode: t
global-company-mode: t
company-mode: t
flycheck-color-mode-line-mode: t
counsel-mode: t
ivy-mode: t
rainbow-delimiters-mode: t
symbol-overlay-mode: t
diff-hl-mode: t
bug-reference-prog-mode: t
paredit-mode: t
goto-address-prog-mode: t
origami-mode: t
guide-key-mode: t
projectile-mode: t
immortal-scratch-mode: t
nyan-mode: t
auto-compile-on-load-mode: t
auto-compile-on-save-mode: t
auto-compile-mode: t
ipretty-mode: t
global-whitespace-cleanup-mode: t
whitespace-cleanup-mode: t
hes-mode: t
whole-line-or-region-global-mode: t
whole-line-or-region-local-mode: t
global-page-break-lines-mode: t
page-break-lines-mode: t
delete-selection-mode: t
cua-mode: t
show-paren-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
global-auto-revert-mode: t
auto-revert-mode: t
savehist-mode: t
desktop-save-mode: t
global-flycheck-mode: t
flycheck-mode: t
diff-auto-refine-mode: t
electric-pair-mode: t
global-anzu-mode: t
anzu-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
global-prettify-symbols-mode: t
prettify-symbols-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
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-xact hides /usr/local/share/emacs/site-lisp/ledger/ledger-xact
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-texi hides /usr/local/share/emacs/site-lisp/ledger/ledger-texi
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-test hides /usr/local/share/emacs/site-lisp/ledger/ledger-test
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-state hides /usr/local/share/emacs/site-lisp/ledger/ledger-state
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-sort hides /usr/local/share/emacs/site-lisp/ledger/ledger-sort
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-schedule hides /usr/local/share/emacs/site-lisp/ledger/ledger-schedule
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-report hides /usr/local/share/emacs/site-lisp/ledger/ledger-report
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-regex hides /usr/local/share/emacs/site-lisp/ledger/ledger-regex
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-reconcile hides /usr/local/share/emacs/site-lisp/ledger/ledger-reconcile
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-post hides /usr/local/share/emacs/site-lisp/ledger/ledger-post
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-occur hides /usr/local/share/emacs/site-lisp/ledger/ledger-occur
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-navigate hides /usr/local/share/emacs/site-lisp/ledger/ledger-navigate
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-mode hides /usr/local/share/emacs/site-lisp/ledger/ledger-mode
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-init hides /usr/local/share/emacs/site-lisp/ledger/ledger-init
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-fonts hides /usr/local/share/emacs/site-lisp/ledger/ledger-fonts
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-fontify hides /usr/local/share/emacs/site-lisp/ledger/ledger-fontify
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-exec hides /usr/local/share/emacs/site-lisp/ledger/ledger-exec
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-context hides /usr/local/share/emacs/site-lisp/ledger/ledger-context
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-complete hides /usr/local/share/emacs/site-lisp/ledger/ledger-complete
/Users/steve/.emacs.d/elpa-26.0/ledger-mode-20170714.1529/ledger-commodities hides /usr/local/share/emacs/site-lisp/ledger/ledger-commodities
/Users/steve/.emacs.d/elpa-26.0/less-css-mode-20160930.2153/less-css-mode hides /usr/local/Cellar/emacs-plus/HEAD-fca6264_2/share/emacs/26.0.50/lisp/textmodes/less-css-mode
Features:
(shadow sort mail-extr emacsbug sendmail pulse two-column iso-transl
org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view
org-bibtex bibtex org-bbdb org-w3m org-capture org-element avl-tree
generator ob-sqlite ob-shell ob-ruby ob-python ob-octave ob-ledger
ob-latex ob-gnuplot ob-dot ob-ditaa ob-R org-clock org org-macro
org-footnote org-pcomplete org-list org-faces org-entities 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 cal-menu
calendar cal-loaddefs align intero docker-tramp tramp-cache tramp
tramp-compat tramp-loaddefs trampver package-lint-test ert parse-time
log-view browse-at-remote eieio-opt speedbar sb-image ezimage dframe
misearch multi-isearch pcmpl-unix move-dup wgrep debug magit-bookmark
magit-obsolete magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-branch
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log magit-diff magit-core magit-autorevert magit-process
magit-margin magit-mode magit-git magit-section magit-popup git-commit
magit-utils crm log-edit pcvs-util add-log with-editor async-bytecomp
async shell pcomplete bookmark rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util
rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-enc
xmltok sanityinc-tomorrow-bright-theme cl-print help-fns
display-line-numbers smex colir cus-edit cus-start cus-load recentf
tree-widget ivy-historian historian company-quickhelp pos-tip winner
sh-script executable tabify view smerge-mode mmm-sample mmm-mode
mmm-univ mmm-class tidy mhtml-mode flyspell ispell vc-mtn vc-hg vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs diff-hl-dired package-build
yaml-mode elisp-slime-nav redshank skeleton aggressive-indent
highlight-quoted add-node-modules-path mmm-erb mmm-region mmm-utils
cursor-sensor company-robe skewer-less rainbow-mode skewer-css
skewer-mode cache-table js2-imenu-extras js2-mode simple-httpd css-eldoc
css-eldoc-hash-table less-css-mode company-dabbrev-code company-dabbrev
company-capf company pcase flycheck-color-mode-line disp-table
rspec-mode cap-words superword subword robe counsel esh-util swiper ivy
flx ivy-overlay ffap rainbow-delimiters symbol-overlay diff-hl vc-dir
ewoc vc vc-dispatcher bug-reference paredit-everywhere paredit goto-addr
origami origami-parsers haml-mode js markdown-mode noutline outline
textile-mode css-mode tagedit sgml-mode color eww mm-url gnus nnheader
wid-edit url-queue shr svg dom browse-url guide-key popwin
projectile-rails rake f inflections inf-ruby ruby-mode smie projectile
grep ibuffer-vc ibuf-ext ibuffer ibuffer-loaddefs immortal-scratch
uptimes init init-locales init-local nyan-mode session
sanityinc-tomorrow-eighties-theme color-theme-sanityinc-tomorrow server
init-ledger init-dash init-folding init-misc init-common-lisp
init-clojure-cider init-clojure init-slime init-lisp flycheck-package
package-lint imenu finder jka-compr cl-lib-highlight auto-compile packed
ipretty pp init-paredit init-docker init-yaml init-toml init-rust
init-sql init-rails init-ruby-mode init-elm init-haskell
init-python-mode init-haml init-css init-html init-nxml init-org
init-php init-javascript ido etags xref project cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
vc-darcs xml init-erlang erlang-start init-csv init-markdown
init-textile init-compile init-projectile init-github init-git
init-darcs init-vc init-fci init-whitespace whitespace-cleanup-mode
whitespace init-editing-utils highlight-escape-sequences
whole-line-or-region page-break-lines delsel cua-base paren warnings
diminish undo-tree diff autorevert filenotify init-mmm mmm-auto mmm-vars
mmm-compat init-fonts init-sessions savehist desktop frameset
init-windows windmove init-company init-hippie-expand init-ivy init-smex
init-recentf init-flycheck face-remap flycheck cl-extra find-func
compile comint ansi-color ring vc-git diff-mode elec-pair autoload
radix-tree lisp-mnt mm-archive message dired-sort help-mode easy-mmode
dired+ image-dired image-mode image-file dired-x dired-aux dired
dired-loaddefs format-spec rfc822 mml mml-sec epa derived epg gnus-util
rmail rmail-loaddefs mailabbrev gmm-utils mailheader mm-decode mm-bodies
mm-encode mail-utils network-stream starttls url-http tls gnutls
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw
nsm subr-x puny url-cache url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
init-ibuffer ibuf-macs init-uniquify init-grep init-isearch anzu
thingatpt init-dired init-gui-frames init-osx-keys init-themes
init-xterm init-frame-hooks init-exec-path exec-path-from-shell
init-elpa fullframe finder-inf gh-common gh-profile s marshal
eieio-compat ht json map dash rx edmacro kmacro slime-autoloads info
package easymenu epg-config url-handlers url-parse auth-source eieio
eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt
bytecomp byte-compile cconv init-site-lisp cl-seq cl gv cl-loaddefs
cl-lib init-utils init-benchmarking advice time-date tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win
ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow
isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded 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 kqueue cocoa ns multi-tty
make-network-process emacs)
Memory information:
((conses 16 2446021 562415)
(symbols 48 70844 553)
(miscs 40 21329 16611)
(strings 32 336099 37699)
(string-bytes 1 8869981)
(vectors 16 137781)
(vector-slots 8 2754255 184771)
(floats 8 1171 8093)
(intervals 56 165629 14869)
(buffers 992 196))
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-08-27 5:40 bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width Steve Purcell
@ 2017-08-27 9:15 ` Stephen Berman
2017-08-27 14:37 ` Eli Zaretskii
2017-08-27 14:32 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Stephen Berman @ 2017-08-27 9:15 UTC (permalink / raw)
To: Steve Purcell; +Cc: 28248
On Sun, 27 Aug 2017 17:40:04 +1200 Steve Purcell <steve@sanityinc.com> wrote:
> When display-line-numbers mode is enabled, this has no effect on the
> return value of window-width or window-text-width, and there is also no
> variable which contains the current width of the line numbers. This all
> means there is no way to determine the width of the text area of the
> window.
>
> This concretely matters to me because my package "page-break-lines"
> remaps the display table of ^L to a horizontal line the width of the
> window: this technique is based on prior art.
The display of the line separating todo and done items in Todo mode
(part of Emacs) is also affected by this. (However, with the default
setup of Todo mode displaying line numbers is unnecessary and even
distracting, since Todo mode already numbers the items by default.)
> I note that turning off fringes *does* correctly adjust
> window-text-width, so it seems that display-line-numbers-mode should do
> the same.
I never tried that before with Todo mode but did just now and see that
it doesn't quite work here: the left side is fine but on the right there
is a continuation character in the last column, so the separator line
breaks on the last character (this is with overflow-newline-into-fringe
set to t, the default).
Steve Berman
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-08-27 5:40 bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width Steve Purcell
2017-08-27 9:15 ` Stephen Berman
@ 2017-08-27 14:32 ` Eli Zaretskii
2017-10-16 21:56 ` Dmitry Gutov
1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2017-08-27 14:32 UTC (permalink / raw)
To: Steve Purcell; +Cc: 28248
> From: Steve Purcell <steve@sanityinc.com>
> Date: Sun, 27 Aug 2017 17:40:04 +1200
>
> When display-line-numbers mode is enabled, this has no effect on the
> return value of window-width or window-text-width
This was discussed at the time, and the decision was not to change the
values those functions return, as we didn't see the need, and similar
display features don't do that as well.
> and there is also no variable which contains the current width of
> the line numbers. This all means there is no way to determine the
> width of the text area of the window.
Yes, there is. From NEWS:
Lisp programs that need to know how much screen estate is used up for
line-number display in a window can use the new function
'line-number-display-width'.
If this doesn't help you solve your problems, please tell the details.
> (PS. nice work on the functionality itself!)
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-08-27 9:15 ` Stephen Berman
@ 2017-08-27 14:37 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2017-08-27 14:37 UTC (permalink / raw)
To: Stephen Berman; +Cc: steve, 28248
> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Sun, 27 Aug 2017 11:15:16 +0200
> Cc: 28248@debbugs.gnu.org
>
> The display of the line separating todo and done items in Todo mode
> (part of Emacs) is also affected by this. (However, with the default
> setup of Todo mode displaying line numbers is unnecessary and even
> distracting, since Todo mode already numbers the items by default.)
>
> > I note that turning off fringes *does* correctly adjust
> > window-text-width, so it seems that display-line-numbers-mode should do
> > the same.
>
> I never tried that before with Todo mode but did just now and see that
> it doesn't quite work here: the left side is fine but on the right there
> is a continuation character in the last column, so the separator line
> breaks on the last character (this is with overflow-newline-into-fringe
> set to t, the default).
It's not clear to me whether you think that display-line-numbers-mode
makes sense together with Todo mode. If it doesn't, one solution is
to turn the display-line-numbers-mode off locally in the buffer when
Todo mode is turned on. If you want to fix your separator line so it
works when line numbers are displayed, please let me know if you need
help doing that, given the information I just posted in this thread.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-08-27 14:32 ` Eli Zaretskii
@ 2017-10-16 21:56 ` Dmitry Gutov
2017-10-17 2:34 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2017-10-16 21:56 UTC (permalink / raw)
To: Eli Zaretskii, Steve Purcell; +Cc: 28248
Hey Eli,
On 8/27/17 5:32 PM, Eli Zaretskii wrote:
>> and there is also no variable which contains the current width of
>> the line numbers. This all means there is no way to determine the
>> width of the text area of the window.
>
> Yes, there is. From NEWS:
>
> Lisp programs that need to know how much screen estate is used up for
> line-number display in a window can use the new function
> 'line-number-display-width'.
Does it work as documented? E.g., I can enable
display-line-numbers-mode, and they will take up 4 visual columns
(numbers plus separators), but (line-number-display-width) returns 2.
Should I always use (+ 2 (line-number-display-width)) instead? That
would be the actual amount of "screen estate used up for line-number
display".
Can I rely on the extra value always being 2?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-16 21:56 ` Dmitry Gutov
@ 2017-10-17 2:34 ` Eli Zaretskii
2017-10-17 6:19 ` Steve Purcell
2017-10-17 8:23 ` Dmitry Gutov
0 siblings, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-17 2:34 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: steve, 28248
> Cc: 28248@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 17 Oct 2017 00:56:45 +0300
>
> > Lisp programs that need to know how much screen estate is used up for
> > line-number display in a window can use the new function
> > 'line-number-display-width'.
>
> Does it work as documented? E.g., I can enable
> display-line-numbers-mode, and they will take up 4 visual columns
> (numbers plus separators), but (line-number-display-width) returns 2.
That's what it should return.
> Should I always use (+ 2 (line-number-display-width)) instead?
If you need it in columns, yes. This is for consistency with the
value of display-line-numbers-width, which you can set.
> That would be the actual amount of "screen estate used up for
> line-number display".
>
> Can I rely on the extra value always being 2?
As long as we don't change the implementation, yes. Alternatively,
you can call line-number-display-width with the optional argument and
get the result in pixels, in which case it includes everything (you
can divide by frame-char-width to get the result back in columns).
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 2:34 ` Eli Zaretskii
@ 2017-10-17 6:19 ` Steve Purcell
2017-10-17 7:01 ` Eli Zaretskii
2017-10-17 8:23 ` Dmitry Gutov
1 sibling, 1 reply; 17+ messages in thread
From: Steve Purcell @ 2017-10-17 6:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 28248, Dmitry Gutov
On 17 Oct 2017, at 15:34, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> That would be the actual amount of "screen estate used up for
>> line-number display".
>>
>> Can I rely on the extra value always being 2?
>
> As long as we don't change the implementation, yes. Alternatively,
> you can call line-number-display-width with the optional argument and
> get the result in pixels, in which case it includes everything (you
> can divide by frame-char-width to get the result back in columns).
Thanks, this is helpful. I have some code which calculates the width of the buffer contents in characters, and calculating this pixelwise works nicely for me.
The odd thing is that there’s a one character discrepancy between graphical and terminal frames. It’s not related to the new line numbers support, since an adjustment for that discrepancy has always been necessary in the code, and the native line numbers are not present in the terminal anyway. Any idea where that one-column difference might be coming from?
https://github.com/purcell/page-break-lines/blob/610dbdc9d39a37912e2b8bfbd3e3d15c7e5d622f/page-break-lines.el#L128-L134
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 6:19 ` Steve Purcell
@ 2017-10-17 7:01 ` Eli Zaretskii
2017-10-17 7:31 ` Steve Purcell
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-17 7:01 UTC (permalink / raw)
To: Steve Purcell; +Cc: 28248, Dmitry Gutov
On October 17, 2017 9:19:11 AM GMT+03:00, Steve Purcell <steve@sanityinc.com> wrote:
> On 17 Oct 2017, at 15:34, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> That would be the actual amount of "screen estate used up for
> >> line-number display".
> >>
> >> Can I rely on the extra value always being 2?
> >
> > As long as we don't change the implementation, yes. Alternatively,
> > you can call line-number-display-width with the optional argument
> and
> > get the result in pixels, in which case it includes everything (you
> > can divide by frame-char-width to get the result back in columns).
>
>
> Thanks, this is helpful. I have some code which calculates the width
> of the buffer contents in characters, and calculating this pixelwise
> works nicely for me.
>
> The odd thing is that there’s a one character discrepancy between
> graphical and terminal frames. It’s not related to the new line
> numbers support, since an adjustment for that discrepancy has always
> been necessary in the code, and the native line numbers are not
> present in the terminal anyway. Any idea where that one-column
> difference might be coming from?
>
> https://github.com/purcell/page-break-lines/blob/610dbdc9d39a37912e2b8bfbd3e3d15c7e5d622f/page-break-lines.el#L128-L134
The space reserved for the continuation glyph? Note that this can also happen
on GUI frames, if the user disables the fringes.
Wouldn't window-text-width suit your needs better?
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 7:01 ` Eli Zaretskii
@ 2017-10-17 7:31 ` Steve Purcell
2017-10-17 8:15 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Steve Purcell @ 2017-10-17 7:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 28248, Dmitry Gutov
On 17 Oct 2017, at 20:01, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Any idea where that one-column
>> difference might be coming from?
>>
>> https://github.com/purcell/page-break-lines/blob/610dbdc9d39a37912e2b8bfbd3e3d15c7e5d622f/page-break-lines.el#L128-L134
>
> The space reserved for the continuation glyph? Note that this can also happen
> on GUI frames, if the user disables the fringes.
>
> Wouldn't window-text-width suit your needs better?
Perhaps, but it returns exactly the same value as window-width in both frame types.
Terminal:
window width: 118
window-width (pix): 118
window-text-width: 118
window-text-width (pix): 118
line-number-display-width: 3
line-number-display-width (pix): 5
margins: (nil)
fringes: (0 0 nil)
frame-char-width: 1
Graphical window (MacOS):
window width: 203
window-width (pix): 1421
window-text-width: 203
window-text-width (pix): 1421
line-number-display-width: 3
line-number-display-width (pix): 35
margins: (nil)
fringes: (8 8 nil)
frame-char-width: 7
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 7:31 ` Steve Purcell
@ 2017-10-17 8:15 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-17 8:15 UTC (permalink / raw)
To: Steve Purcell; +Cc: 28248, Dmitry Gutov
On October 17, 2017 10:31:56 AM GMT+03:00, Steve Purcell <steve@sanityinc.com> wrote:
> On 17 Oct 2017, at 20:01, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> Any idea where that one-column
> >> difference might be coming from?
> >>
> >>
> https://github.com/purcell/page-break-lines/blob/610dbdc9d39a37912e2b8bfbd3e3d15c7e5d622f/page-break-lines.el#L128-L134
> >
> > The space reserved for the continuation glyph? Note that this can
> also happen
> > on GUI frames, if the user disables the fringes.
> >
> > Wouldn't window-text-width suit your needs better?
>
>
> Perhaps, but it returns exactly the same value as window-width in both
> frame types.
>
> Terminal:
>
> window width: 118
> window-width (pix): 118
> window-text-width: 118
> window-text-width (pix): 118
> line-number-display-width: 3
> line-number-display-width (pix): 5
> margins: (nil)
> fringes: (0 0 nil)
> frame-char-width: 1
>
> Graphical window (MacOS):
>
> window width: 203
> window-width (pix): 1421
> window-text-width: 203
> window-text-width (pix): 1421
> line-number-display-width: 3
> line-number-display-width (pix): 35
> margins: (nil)
> fringes: (8 8 nil)
> frame-char-width: 7
Sorry, you are right (too many different functions, all alike). I meant
window-max-chars-per-line.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 2:34 ` Eli Zaretskii
2017-10-17 6:19 ` Steve Purcell
@ 2017-10-17 8:23 ` Dmitry Gutov
2017-10-17 16:33 ` Eli Zaretskii
1 sibling, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2017-10-17 8:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: steve, 28248
On 10/17/17 5:34 AM, Eli Zaretskii wrote:
>> Should I always use (+ 2 (line-number-display-width)) instead?
>
> If you need it in columns, yes. This is for consistency with the
> value of display-line-numbers-width, which you can set.
>
>> That would be the actual amount of "screen estate used up for
>> line-number display".
>>
>> Can I rely on the extra value always being 2?
>
> As long as we don't change the implementation, yes. Alternatively,
> you can call line-number-display-width with the optional argument and
> get the result in pixels, in which case it includes everything (you
> can divide by frame-char-width to get the result back in columns).
Thanks, but isn't that more inconsistent? I would expect both return
values of this function to measure the same thing, and there's nothing
in the docstring to explain that difference.
On the other hand, the return value of the function can differ from what
a variable is set to.
I guess I could live with that, but the function's docstring needs updating.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 8:23 ` Dmitry Gutov
@ 2017-10-17 16:33 ` Eli Zaretskii
2017-10-18 0:33 ` Dmitry Gutov
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-17 16:33 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: steve, 28248
> Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 17 Oct 2017 11:23:56 +0300
>
> On 10/17/17 5:34 AM, Eli Zaretskii wrote:
>
> >> Should I always use (+ 2 (line-number-display-width)) instead?
> >
> > If you need it in columns, yes. This is for consistency with the
> > value of display-line-numbers-width, which you can set.
> >
> >> That would be the actual amount of "screen estate used up for
> >> line-number display".
> >>
> >> Can I rely on the extra value always being 2?
> >
> > As long as we don't change the implementation, yes. Alternatively,
> > you can call line-number-display-width with the optional argument and
> > get the result in pixels, in which case it includes everything (you
> > can divide by frame-char-width to get the result back in columns).
>
> Thanks, but isn't that more inconsistent? I would expect both return
> values of this function to measure the same thing, and there's nothing
> in the docstring to explain that difference.
They are used for 2 different purposes, which are contradictory to
some degree. The value in column units is primarily meant to be used
for setting display-line-numbers-width (see, e.g., how
display-line-numbers.el uses that), and also for users, so burdening
them with anything that is not directly related to the value of the
largest visible line number would be a nuisance. OTOH, the
column-unit value is of limited utility for layout calculations,
because the columns are of the line-number face, which could be
smaller or larger than the default face. Therefore, layout
calculations should use the function's pixelwise variety, and convert
into columns by dividing by the width of the font used for buffer
text. (Which btw means my response to you earlier -- see above -- was
incomplete: you should use the function in pixel-unit mode, if you
need to account for the screen space eaten by line numbers, and then
you don't have to add anything to the value it returns.)
And I just noticed that we do use the column-unit values in some of
the places in Emacs that need this, so I will be fixing them soon.
> On the other hand, the return value of the function can differ from what
> a variable is set to.
I think that'd be a nuisance; again, see what display-line-numbers.el
does.
I agree that this is not ideal, to say the least, but I hope you at
least understand the issues now. If there's a better solution, I'm
all ears.
> the function's docstring needs updating.
Done.
Thanks.
P.S. I'd still like to hear your opinions on the related questions I
asked here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28855#8
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-17 16:33 ` Eli Zaretskii
@ 2017-10-18 0:33 ` Dmitry Gutov
2017-10-18 16:35 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2017-10-18 0:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: steve, 28248
On 10/17/17 7:33 PM, Eli Zaretskii wrote:
> They are used for 2 different purposes, which are contradictory to
> some degree.
But that's true for all core functions with a PIXELWISE argument, isn't
it? Yet, the rest measure the same thing in both cases, AFAIK.
> The value in column units is primarily meant to be used
> for setting display-line-numbers-width (see, e.g., how
> display-line-numbers.el uses that), and also for users, so burdening
> them with anything that is not directly related to the value of the
> largest visible line number would be a nuisance.
Maybe display-line-numbers-width could include the separator columns as
well.
> OTOH, the
> column-unit value is of limited utility for layout calculations,
> because the columns are of the line-number face, which could be
> smaller or larger than the default face.
That changes little for me: overlay-based layout can't do anything with
pixels anyway. If all I can do is divine the resulting value by
frame-char-width and hope for the best, I might as well use the return
value in columns to begin with.
Furthermore, in Company, we already call similar functions (like
window-body-height) with PIXELWISE nil.
> Therefore, layout
> calculations should use the function's pixelwise variety, and convert
> into columns by dividing by the width of the font used for buffer
> text. (Which btw means my response to you earlier -- see above -- was
> incomplete: you should use the function in pixel-unit mode, if you
> need to account for the screen space eaten by line numbers, and then
> you don't have to add anything to the value it returns.)
I can't help but worry about how an off-by-one error in pixel width
(which is not strictly defined) would result in an off-by-one error in
column width after division. And again, I'm in no position to use the
pixelwise value.
>> On the other hand, the return value of the function can differ from what
>> a variable is set to.
>
> I think that'd be a nuisance; again, see what display-line-numbers.el
> does.
>
> I agree that this is not ideal, to say the least, but I hope you at
> least understand the issues now. If there's a better solution, I'm
> all ears.
display-line-numbers-update-width might look worse, I agree. But we
could have two functions, right? Both line-number-display-width and
display-line-numbers-update-width could delegate to
line-number-display-inner-width.
Just a suggestion.
>> the function's docstring needs updating.
>
> Done.
Thank you.
> P.S. I'd still like to hear your opinions on the related questions I
> asked here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28855#8
Sorry, I haven't noticed your question, and I don't know what :align-to
is about. And to be frank, I don't understand that question now.
I'll try to re-read and respond.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-18 0:33 ` Dmitry Gutov
@ 2017-10-18 16:35 ` Eli Zaretskii
2017-10-18 22:40 ` Dmitry Gutov
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-18 16:35 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: steve, 28248
> Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 18 Oct 2017 03:33:52 +0300
>
> On 10/17/17 7:33 PM, Eli Zaretskii wrote:
>
> > They are used for 2 different purposes, which are contradictory to
> > some degree.
>
> But that's true for all core functions with a PIXELWISE argument, isn't
> it? Yet, the rest measure the same thing in both cases, AFAIK.
It's not uncommon in Emacs to have optional arguments that modify the
behavior of a function and thus affect their results. It could be
that this is the first such function whose optional argument happens
to be called PIXELWISE, but if thats the problem, we can easily change
the name, and I will probably do so.
> > The value in column units is primarily meant to be used
> > for setting display-line-numbers-width (see, e.g., how
> > display-line-numbers.el uses that), and also for users, so burdening
> > them with anything that is not directly related to the value of the
> > largest visible line number would be a nuisance.
>
> Maybe display-line-numbers-width could include the separator columns as
> well.
I think I will add a 3rd value of the PIXELWISE argument, which will
report the full width, but in units of the frame's canonical character
(such a result will have to be a float, though). I think this will
satisfy your needs, and the needs of other applications. Do you
agree?
> > OTOH, the
> > column-unit value is of limited utility for layout calculations,
> > because the columns are of the line-number face, which could be
> > smaller or larger than the default face.
>
> That changes little for me: overlay-based layout can't do anything with
> pixels anyway. If all I can do is divine the resulting value by
> frame-char-width and hope for the best, I might as well use the return
> value in columns to begin with.
Are we miscommunicating? The value returned by the function when its
optional argument is nil or omitted is in columns of the line-number
face, not of the frame's default face. E.g., if someone customizes
line-number to use a font that is twice as large as that used for
'default', the result will be half of what you'd expect. So dividing
by frame-char-face is exactly the wrong thing.
In a nutshell, when the optional arg is nil, the return value is the
number of digits allocated/used for displaying the numbers, not the
number of columns it takes. I hope I've succeeded in explaining the
issue now.
> Furthermore, in Company, we already call similar functions (like
> window-body-height) with PIXELWISE nil.
That function returns its value in units of frame's canonical
character width, so it suits your needs much better.
> I can't help but worry about how an off-by-one error in pixel width
> (which is not strictly defined) would result in an off-by-one error in
> column width after division. And again, I'm in no position to use the
> pixelwise value.
The division should be done with floats, then the accuracy loss due to
off-by-one errors will not be that catastrophic.
> > I agree that this is not ideal, to say the least, but I hope you at
> > least understand the issues now. If there's a better solution, I'm
> > all ears.
>
> display-line-numbers-update-width might look worse, I agree. But we
> could have two functions, right? Both line-number-display-width and
> display-line-numbers-update-width could delegate to
> line-number-display-inner-width.
>
> Just a suggestion.
I think it's better to keep the number of similar functions to a
minimum, otherwise it's hard top remember which does what. I see no
problem to have a single function serve 2 or 3 different purposes,
controlled by optional arguments. We do this elsewhere.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-18 16:35 ` Eli Zaretskii
@ 2017-10-18 22:40 ` Dmitry Gutov
2017-10-19 3:15 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Dmitry Gutov @ 2017-10-18 22:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: steve, 28248
On 10/18/17 7:35 PM, Eli Zaretskii wrote:
> It's not uncommon in Emacs to have optional arguments that modify the
> behavior of a function and thus affect their results. It could be
> that this is the first such function whose optional argument happens
> to be called PIXELWISE, but if thats the problem, we can easily change
> the name, and I will probably do so.
The other functions with PIXELWISE argument just have it change the
return value to be pixelwise, that's all. So I'm for consistency here.
With the changed name, it will be the first function to have an argument
that controls pixelwise-ness, that is named something else :)
> I think I will add a 3rd value of the PIXELWISE argument, which will
> report the full width, but in units of the frame's canonical character
> (such a result will have to be a float, though). I think this will
> satisfy your needs, and the needs of other applications. Do you
> agree?
Sure. Although I'd rather the third value made it return the "inner"
width, and nil and t meant to measure the same thing (at the cost in
some backward incompatibility with the pre-release Emacs versions). But,
again, I'm not saying this issue is critical.
> Are we miscommunicating? The value returned by the function when its
> optional argument is nil or omitted is in columns of the line-number
> face, not of the frame's default face. E.g., if someone customizes
> line-number to use a font that is twice as large as that used for
> 'default', the result will be half of what you'd expect. So dividing
> by frame-char-face is exactly the wrong thing.
All right, that's a good point, thank you. I'll look into this again
when I revisit the code.
> The division should be done with floats, then the accuracy loss due to
> off-by-one errors will not be that catastrophic.
Hmm, maybe so. But then we'll have to switch to floats everywhere, for
this to have a meaningful benefit.
> I think it's better to keep the number of similar functions to a
> minimum, otherwise it's hard top remember which does what. I see no
> problem to have a single function serve 2 or 3 different purposes,
> controlled by optional arguments. We do this elsewhere.
Sounds GTM.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-18 22:40 ` Dmitry Gutov
@ 2017-10-19 3:15 ` Eli Zaretskii
2017-10-20 9:44 ` Eli Zaretskii
0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-19 3:15 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: steve, 28248
> Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 19 Oct 2017 01:40:15 +0300
>
> > The division should be done with floats, then the accuracy loss due to
> > off-by-one errors will not be that catastrophic.
>
> Hmm, maybe so. But then we'll have to switch to floats everywhere, for
> this to have a meaningful benefit.
:align-to already supports floats.
> > I think it's better to keep the number of similar functions to a
> > minimum, otherwise it's hard top remember which does what. I see no
> > problem to have a single function serve 2 or 3 different purposes,
> > controlled by optional arguments. We do this elsewhere.
>
> Sounds GTM.
OK, I will make that change soon.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width
2017-10-19 3:15 ` Eli Zaretskii
@ 2017-10-20 9:44 ` Eli Zaretskii
0 siblings, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2017-10-20 9:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: steve, 28248, dgutov
> Date: Thu, 19 Oct 2017 06:15:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: steve@sanityinc.com, 28248@debbugs.gnu.org
>
> > > I think it's better to keep the number of similar functions to a
> > > minimum, otherwise it's hard top remember which does what. I see no
> > > problem to have a single function serve 2 or 3 different purposes,
> > > controlled by optional arguments. We do this elsewhere.
> >
> > Sounds GTM.
>
> OK, I will make that change soon.
Done.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2017-10-20 9:44 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-27 5:40 bug#28248: 26.0.50; display-line-numbers does not affect window-width / window-text-width Steve Purcell
2017-08-27 9:15 ` Stephen Berman
2017-08-27 14:37 ` Eli Zaretskii
2017-08-27 14:32 ` Eli Zaretskii
2017-10-16 21:56 ` Dmitry Gutov
2017-10-17 2:34 ` Eli Zaretskii
2017-10-17 6:19 ` Steve Purcell
2017-10-17 7:01 ` Eli Zaretskii
2017-10-17 7:31 ` Steve Purcell
2017-10-17 8:15 ` Eli Zaretskii
2017-10-17 8:23 ` Dmitry Gutov
2017-10-17 16:33 ` Eli Zaretskii
2017-10-18 0:33 ` Dmitry Gutov
2017-10-18 16:35 ` Eli Zaretskii
2017-10-18 22:40 ` Dmitry Gutov
2017-10-19 3:15 ` Eli Zaretskii
2017-10-20 9:44 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).