bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23598: 25.0.94; linum


From: Stefan Kangas
Subject: bug#23598: 25.0.94; linum
Date: Tue, 11 Aug 2020 19:20:28 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]