Sun 26 Feb 2017 12:35:57 PM UTC, comment #1:
(The issue with reading in a large file has been rereported as bug #50406. The current bug will be only about --constantshow.)
To reproduce, run 'for x in $(seq 45); do cat src/.c >>million; done'. Open the file: 'nano --ignore --constant million'. Type <Down> a few times. Nano responds virtually instantly. Now type M-/. It takes eight* seconds before nano finally shows the bottom of the file. This is unusable. Now type <Up> a few times quickly in a row. It takes nano again eight seconds to show the result of the first <Up>, and another eight seconds to show the result of the rest of the keystrokes. Useless.
With constant position display, nano recomputes the number of characters up to the position of the cursor /every/ time the cursor is moved. This is an enormous waste of time.
If you open the same file with Pico, the result of typing ^C is nearly instantaneous, wherever the cursor is in the file. I am guessing that Pico stores the number of characters that each line contains, and when ^C is pressed, it quickly adds up all these numbers of the lines before the cursor, plus the number of characters on the current line before the cursor. Nano should do something similar, because recounting all the characters up to the cursor for every keystroke is utterly wasteful.
This is not so easy, though: when cutting or pasting text, things can be cut or inserted midline, so it will take a lot of extra hassle to get the character counts for each affected line right.
|