bug#23598: 25.0.94; linum

bug#23598: 25.0.94; linum

[freezer]

Good morning,

1. When I turn on line numbers (with linum-mode), scrolling a large org 
file is
very slow. This only happens when the org sections are folded and not 
fully
expanded.
2. With some themes, the line numbers are also truncated.  Example 
(theme
monokai): http://i.imgur.com/gkY8FGn.png

Example org file:
https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org



In GNU Emacs 25.0.94.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
  of 2016-05-22 built on workstation
Windowing system distributor 'The X.Org Foundation', version 
11.0.11803000
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL
GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LC_COLLATE: C
   value of $LANG: en_US.utf8
   locale-coding-system: utf-8-unix

Major mode: Org

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

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
next-line: End of buffer [3 times]
Linum mode enabled in current buffer
previous-line: Beginning of buffer
next-line: End of buffer

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec
password-cache epg epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns help-mode mail-prsvr mail-utils linum
org-element org-rmail org-mhe org-irc org-info org-gnus gnus-util
org-docview doc-view subr-x jka-compr image-mode dired cl-loaddefs pcase
cl-lib org-bibtex bibtex org-bbdb org-w3m 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 ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu easymenu
calendar cal-loaddefs time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help
simple abbrev 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
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 174600 18527)
  (symbols 48 26303 0)
  (miscs 40 8375 87)
  (strings 32 41745 6677)
  (string-bytes 1 1131856)
  (vectors 16 18240)
  (vector-slots 8 496159 4019)
  (floats 8 212 79)
  (intervals 56 6263 0)
  (buffers 976 12)
  (heap 1024 52971 1522))

bug#23598: 25.0.94; linum

[Eli Zaretskii]

> Date: Sun, 22 May 2016 08:59:35 +0200
> From: freezer@posteo.de
> 
> 1. When I turn on line numbers (with linum-mode), scrolling a large org file is very slow. This only happens when the org sections are folded and not fully
> expanded.

linum-mode needs to count lines each time you scroll through the file,
and it needs to update the display for all the lines visible in the
window.  When many lines are hidden, updating a window requires
traversing a lot of lines in the buffer.  For example, the sample file
you sent shows almost 3000 lines in a single window, which is 100
times more than an average window without hidden lines.  So yes, this
is slow.

I suggest to switch to nlinum-mode from ELPA, which us much faster in
these cases.

> 2. With some themes, the line numbers are also truncated. Example (theme
> monokai): http://i.imgur.com/gkY8FGn.png
> 
> Example org file:
> https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org

The monokai theme seems to implicitly enlarge the face used for the
line numbers and change its font (because Org headers use an enlarged
variable-pitch font), but it doesn't update the 'linum' face with that
information.  By default, the face for the line numbers has its
attributes merged with those of the face used to display the text
line, and since the 'linum' face by default doesn't specify any size
or font attributes, they are taken from the Org header face.  So the
calculation of character size linum-mode does is incorrect, because
the 'linum' face's font is still defined to be the original size
before it was enlarged.  I think setting the 'linum' face's attributes
to set specific font family and height attributes should fix this
problem.  It could be argued that the monokai theme should do that: it
clearly caters to linum-mode, since it does set some attributes of the
'linum' face.

bug#23598: 25.0.94; linum

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 22 May 2016 08:59:35 +0200
>> From: freezer@posteo.de
>>
>> 1. When I turn on line numbers (with linum-mode), scrolling a large org file is very slow. This only happens when the org sections are folded and not fully
>> expanded.
>
> linum-mode needs to count lines each time you scroll through the file,
> and it needs to update the display for all the lines visible in the
> window.  When many lines are hidden, updating a window requires
> traversing a lot of lines in the buffer.  For example, the sample file
> you sent shows almost 3000 lines in a single window, which is 100
> times more than an average window without hidden lines.  So yes, this
> is slow.
>
> I suggest to switch to nlinum-mode from ELPA, which us much faster in
> these cases.
>
>> 2. With some themes, the line numbers are also truncated. Example (theme
>> monokai): http://i.imgur.com/gkY8FGn.png
>>
>> Example org file:
>> https://github.com/syl20bnr/spacemacs/blob/master/doc/DOCUMENTATION.org
>
> The monokai theme seems to implicitly enlarge the face used for the
> line numbers and change its font (because Org headers use an enlarged
> variable-pitch font), but it doesn't update the 'linum' face with that
> information.  By default, the face for the line numbers has its
> attributes merged with those of the face used to display the text
> line, and since the 'linum' face by default doesn't specify any size
> or font attributes, they are taken from the Org header face.  So the
> calculation of character size linum-mode does is incorrect, because
> the 'linum' face's font is still defined to be the original size
> before it was enlarged.  I think setting the 'linum' face's attributes
> to set specific font family and height attributes should fix this
> problem.  It could be argued that the monokai theme should do that: it
> clearly caters to linum-mode, since it does set some attributes of the
> 'linum' face.

So the suggestion here is to use nlinum-mode instead for these cases,
and to potentially also make changes to an external theme.

So is there anything more to do here or should this be closed?

Best regards,
Stefan Kangas

bug#23598: 25.0.94; linum

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 11 Aug 2020 19:20:28 -0700
> Cc: freezer@posteo.de, 23598@debbugs.gnu.org
> 
> So the suggestion here is to use nlinum-mode instead for these cases,
> and to potentially also make changes to an external theme.
> 
> So is there anything more to do here or should this be closed?

I think we can close this, especially given that we now have
display-line-numbers.

bug#23598: 25.0.94; linum

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I think we can close this, especially given that we now have
> display-line-numbers.

Thanks, closing this now.

Best regards,
Stefan Kangas