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