GNU nano - Bugs: bug #51491, any cursor movement on a huge...
You are not allowed to post comments on this tracker with your current authentication level.
bug #51491: any cursor movement on a huge softwrapped line is slow
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Mon 17 Jul 2017 11:55:56 AM UTC | ||
Severity: | 2 - Minor | Status: | Wont Fix |
Assigned to: | None | Open/Closed: | Closed |
Jump to the original submission
Sun 01 Dec 2019 04:17:55 PM UTC, comment #19: |
Benno Schulenberg <bens> |
Fri 13 Jul 2018 10:43:07 AM UTC, comment #18: Commit 9a7ba5db is not a true fix, of course. Things would be fixed if moving the cursor anywhere in a huge softwrapped line would always take the same amount of time. But that is not the case, and would require enormous changes to achieve. So... letting it be for now, and downscaling the importance, as the named commit has improved things quite a bit. |
Benno Schulenberg <bens> |
Tue 05 Jun 2018 07:15:18 PM UTC, comment #17: I haven't done official measurements either, but I have tested current git with an ASCII file consisting of one line of almost 50k (both before and after the commit you mention), and it's noticeably faster after the commit. |
David Lawrence Ramsey <dolorous> |
Mon 04 Jun 2018 12:19:07 PM UTC, comment #16: Forgot to say: the first hunk in that commit speeds up things by roughly a factor of two. The second hunk seems to have the most effect: an additional factor of three or four or five -- I haven't done any actual measurements. |
Benno Schulenberg <bens> |
Mon 04 Jun 2018 12:15:09 PM UTC, comment #15: Commit 9a7ba5db improves this significantly. To verify, make your terminal at least 32 rows high and 135 coluns wide, and then run the following command, both for nano 2.9.8 (or older) and for current git:
|
Benno Schulenberg <bens> |
Sat 21 Apr 2018 11:03:10 AM UTC, comment #14: Gnulib's wcwidth() is only used because you are on a Mac, where the system's wcwidth() has some obscure bug. On most systems, glibc is present and the system's wcwidth() is fine and is used.
|
Benno Schulenberg <bens> |
Wed 18 Apr 2018 09:34:48 PM UTC, comment #13: I found by profiling that the real issue here is GNULib's wcwidth implementation.
|
easyaspi314 <easyaspi314> |
Mon 30 Oct 2017 08:50:28 PM UTC, comment #12: Okay. I suppose that something like it would only be acceptable if it's part of a larger attempt at caching softwrap data, but that would of course take much more time and effort to implement. |
David Lawrence Ramsey <dolorous> |
Mon 30 Oct 2017 08:18:52 PM UTC, comment #11: There is some improvement, but it's "too small" -- it's not a difference of day and night, so I don't think it's worth the extra code. |
Benno Schulenberg <bens> |
Sun 29 Oct 2017 07:25:37 PM UTC, comment #10: Since it's been awhile, I've attached a resync of the second patch against git 3f27c31. |
David Lawrence Ramsey <dolorous> |
Thu 20 Jul 2017 10:44:25 AM UTC, comment #9: For now, I've just applied the second patch (after updating it for the unchanged line), as it's obviously correct.
|
Benno Schulenberg <bens> |
Thu 20 Jul 2017 03:24:32 AM UTC, comment #8: Forget that last patch; it doesn't build in tiny mode.
|
David Lawrence Ramsey <dolorous> |
Thu 20 Jul 2017 01:44:19 AM UTC, comment #7: How about the attached patch, against git 0e4cbd4? It saves the number of softwrapped chunks before firstcolumn in the openfilestruct, and only changes it when firstcolumn changes, thus eliminating the need to calculate it on the fly every single time. |
David Lawrence Ramsey <dolorous> |
Wed 19 Jul 2017 09:40:38 AM UTC, comment #6: Up to five thousand columns, performance is acceptable. But when the cursor is around column ten thousand... even every move of the cursor lags, also a simple <Left> or <Right> -- which don't change chunk and should therefore be instantaneous.
|
Benno Schulenberg <bens> |
Tue 18 Jul 2017 12:01:41 AM UTC, comment #5: Besides, the new softwrap treats two-column control characters and two-column Unicode characters in the same fashion, in terms of display and movement. Given that, in terms of softwrap navigation, there's no difference between a binary file (a bunch of two-column control characters, plus irregular spacing and tabs) and a text file written in, say, two-column Chinese characters, with the same irregular spacing and tabs, plus a mixture of Unix, DOS, and Mac newlines.
|
David Lawrence Ramsey <dolorous> |
Mon 17 Jul 2017 07:55:09 PM UTC, comment #4: Define "if the scrolling behaves a little weird there". nano isn't meant to be a binary editor, no, but it should still function properly if the file contains binary garbage. |
David Lawrence Ramsey <dolorous> |
Mon 17 Jul 2017 06:52:06 PM UTC, comment #3: Hmmm... Working backward (without --atblanks) might put a leftedge one (single-width) character too far back, but... if my powers of imagination are right, this one-off placement cannot accumulate, the misplacement cannot get bigger than one (single-width) character off.
|
Benno Schulenberg <bens> |
Mon 17 Jul 2017 03:56:19 PM UTC, comment #2: Actually, after some checking, edit_scroll() does have to redraw the entire line, but that's because it uses update_softwrapped_line(), which does that. That's useful if the text has changed, but in this case, we've only moved, so it hasn't. |
David Lawrence Ramsey <dolorous> |
Mon 17 Jul 2017 03:47:31 PM UTC, comment #1: Redrawing the screen already tells ncurses to move the text one row down and redraw only the top row; that's what edit_scroll() does, and M+- indirectly calls it.
|
David Lawrence Ramsey <dolorous> |
Mon 17 Jul 2017 11:55:56 AM UTC, original submission:
Open some file that contains a line of enormous length. Find that line and press <End> <End> on it, so we're actually at the very end of that line. Then type M+- (that is: order nano to move the whole text one row down). This takes something like two seconds.
|
Benno Schulenberg <bens> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 14 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2019-12-01 | bens | Status | None | Wont Fix | |
Open/Closed | Open | Closed | |||
2018-07-13 | bens | Severity | 3 - Normal | 2 - Minor | |
Status | Ready For Test | None | |||
Assigned to | bens | None | |||
2018-06-04 | bens | Status | None | Ready For Test | |
Assigned to | None | bens | |||
2018-04-18 | easyaspi314 | Attached File | - | Added no_gnulib_wcwidth.patch, #43970 | |
2017-10-29 | dolorous | Attached File | - | Added 0001-softwrap-save-the-number-of-softwrapped-chunks-befor.patch, #42293 | |
2017-07-20 | dolorous | Attached File | - | Added 0001-softwrap-save-the-number-of-softwrapped-chunks-befor.patch, #41258 | |
Attached File | - | Added 0002-softwrap-only-compensate-for-partially-offscreen-lin.patch, #41259 | |||
2017-07-20 | dolorous | Attached File | - | Added 0001-softwrap-save-the-number-of-softwrapped-chunks-befor.patch, #41257 | |
2017-07-19 | bens | Summary | scrolling up one row on a huge softwrapped line takes too long | any cursor movement on a huge softwrapped line is slow | |
2017-07-17 | bens | Carbon-Copy | - | Added dolorous |
Powered by Savane 3.13-758e.
Corresponding source code
The various optimizations to the character-parsing routines have brought considerable speedup for plain-ASCII texts. Until an actual user complains about slowness with a real-world file, I'm going to let this be.