GNU nano - Patches: patch #10205, paint: truncate lines before...
You are not allowed to post comments on this tracker with your current authentication level.
patch #10205: paint: truncate lines before calling regexec()
Submitter: | easyaspi314 <easyaspi314> | ||
Submitted: | Mon 09 May 2022 05:07:07 AM UTC | ||
Priority: | 3 - Low | Status: | Wont Do |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Release: | None |
Thu 12 May 2022 04:01:12 PM UTC, comment #2: |
easyaspi314 <easyaspi314> |
Thu 12 May 2022 02:39:16 PM UTC, comment #1: Hmm... Not worth the expense. I've already gritted my teeth at the added 'index < PAINT_LIMIT' for every stretch of paint, but I've gone with it because it is very little code and just two nanoseconds. But adding a strnln() (before painting any line) that for the vast, vast majority of lines is a waste of time... No, that is too much. It would be useful only for pathological files, and the rendering of those has been improved enough with the simple 'index < PAINT_LIMIT'. It's much better to try and make small improvements in the general painting of lines, so that all files profit. |
Benno Schulenberg <bens>![]() |
Mon 09 May 2022 05:07:07 AM UTC, original submission:
The previous solution didn't stop regexec() from scanning to the end of the string if a rule did not match before then.
|
easyaspi314 <easyaspi314> |
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-05-12 | bens | Priority | 5 - Normal | ![]() |
3 - Low |
Status | None | ![]() |
Wont Do | ||
2022-05-09 | easyaspi314 | Attached File | - | ![]() |
Added 0001-Truncate-lines-before-calling-regexec.patch, #53182 |
This was just trying to correct what the PAINT_LIMIT tried to do as a temporary fix. I am aware of two serious issues with the syntax highlighting:
- The syntax highlighting is calculated multiple times for softwrap
- The nested actual_x and wideness calls could be optimized to start from the last known column
One thing that might be of interest is mvwchgat(), which allows changing the attributes of a section of a line without overwriting with a string. This means that it can potentially be done in one pass without access to the converted string.