Clean up

[ProgerXP]

trafficstars

Please move HightLightSelection and WheelScroll from [Settings] to [extended] INI group in the code - I have updated the INI already.

[ghost]

fixed

[ProgerXP]

I am trying to check if the INI settings we have created during other tasks work or not. I can't get these to have any effect, please check how/if they are used:

• HightLightSelection - even if 0 selection is still highlighted.
• MaxSearchDistance - if I set it to 1 (so supposedly = 1 kilobyte) and make a document like zz\n...\nzz where ... stands for 1500 lines that make up for 35 kilobytes, then if I put caret at first zz that zz is highlighted as per single occurrence mode (correct). However, if I scroll down to the last line (with zz) while first zz is still at the cursor - last zz gets highlighted as if there were multiple occurrences that are not all seen on screen (this would be correct if MaxSearchDistance was large enough; but with 1 kilobyte it should not be).
• ActiveSelectionBackground and ActiveSelectionForeground - what do they do? They seem to be no effect at all.

[ProgerXP]

So?

[ghost]

I will reply later. Now I'm busy. There's a lot of work here.

I can make a short review:

• MaxSearchDistance - it's used as expected. Your words need a full testing.
• I can say about all my INI settings. I read these settings ,but I don't write its to INI file.

[ProgerXP]

I can say about all my INI settings. I read these settings ,but I don't write its to INI file.

That's okay, you should only read them.

[ProgerXP]

@ haccel One month has passed.

[ProgerXP]

• MaxSearchDistance - if I set it to 1 (so supposedly = 1 kilobyte) and make a document like zz\n...\nzz where ... stands for 1500 lines that make up for 35 kilobytes, then if I put caret at first zz that zz is highlighted as per single occurrence mode (correct). However, if I scroll down to the last line (with zz) while first zz is still at the cursor - last zz gets highlighted as if there were multiple occurrences that are not all seen on screen (this would be correct if MaxSearchDistance was large enough; but with 1 kilobyte it should not be).

1. I have made a file of 100 000 lines = zz (390 KiB) and set MaxSearchDistance to 1. Then I put the caret at the last line and scrolled up (with the mouse on the scrollbar) - all 100k lines were highlighted. Why?

2. I have made a file of 100 000 lines = xx, set MaxSearchDistance to 1 and added a line = zz as last line plus a line = zz ~170 lines below the last line. The added line wasn't highlighted (this is correct) because the distance between two zzs is > 1 KiB. I have moved the line down a few lines so it's now highlighted (also correct). But now I have moved the line up - I expected that since I found the limit at which both lines are recognized, after moving it up I will be outside of that limit and the word wouldn't be highlighted. But it was highlighted!

In other words, if top zz line is at line A and Notepad highlights it as if it had no matching word (because the distance is too far), and then you move zz to line A+1 and Notepad highlights it as if it had a pair - then I expect that if I move zz back to line A (from A+1 to A) - it will be again not highlighted. But it is highlighted and highlighting only changes to no-match if I move the line to A-10 or so.

[cshnik]

I reviewed the sources and found "MaxSearchDistance"-setting is actually used as a limiter for the "edit selection"-modes (Ctrl+Tab/Ctrl+~), i.e. MaxSearchDistance=1 means "Edit Selection" will work only for the first +/-1KB area from current position. This setting never affected the way "Text highlighting"-subroutine works.

[ProgerXP]

This is not the intended behaviour, it must be a misimplementation.

The intention is to have a setting that controls word (or selection) highlighting. This is because there may be very large documents so that highlighting must be limited to a reasonable distance from the cursor, both sides. The default must be 64 KiB plus and 64 KiB minus the current position.

The Edit Selection function only affects visible lines. Because it's hard to detect visibility boundaries in Scintilla (due to word wrapping), it's still possible that the editor may hang on extremely long lines. So it's a good idea to limit Edit Selection to some distance too.

But it doesn't make sense to limit only Edit Selection.

Do you see my intention?

[cshnik]

I was mistaken. MaxSearchDistance actually affects highlighting and works the way you described it (with required area limits and performance). But there is a feature in its implementation: you can't see/track that limit if there is a match visible on current page. It looks like an UI enhancement to make application behave user-friendly. Please note, there are different types of highlighting (indicators) specific to next states: a) multiple matches in document, not all of them are visible on screen b) single match in document c) mutliple matches visible on screen d) edit state flag And these types of highlighting works slightly different.

Regarding the case (2) it looks like I was able to reproduce it and the reason of this unusual behavior relates to scrolling of the file contents. The point is: scrolling of the lines affects the area range tested for word matching and depends on the first visible line index.

[ProgerXP]

But there is a feature in its implementation: you can't see/track that limit if there is a match visible on current page. It looks like an UI enhancement to make application behave user-friendly.

This is still a problem because in large documents this would make the program unresponsible. Needs to be fixed.

And these types of highlighting works slightly different.

The 4 states are correct. What are their differences?

Regarding the case (2) it looks like I was able to reproduce it and the reason of this unusual behavior relates to scrolling of the file contents. The point is: scrolling of the lines affects the area range tested for word matching and depends on the first visible line index.

So highlighting is performed when scrolling, not when changing cursor position? But even in this case, highlighting is detected based on the cursor position which doesn't change; if I scroll to lines that are N-L or N+L (N=cursor; L=limit) bytes far - highlighting must stop. This seems logical.

[cshnik]

This is still a problem because in large documents this would make the program unresponsible. Needs to be fixed.

The problem is caused by frequent and long document updates when scrolling or changing cursor position.

The 4 states are correct. What are their differences?

These are already documented in the README.MD (Current Word Highlighting)

So highlighting is performed when scrolling, not when changing cursor position? But even in this case, highlighting is detected based on the cursor position which doesn't change; if I scroll to lines that are N-L or N+L (N=cursor; L=limit) bytes far - highlighting must stop. This seems logical.

Any user input activity which may cause UI change is handled by Scintilla and is transferred within "UpdateUI" notifications to main window. "Highlight word" feature will change indicators state to show all indicators correctly/matching the current UI state (respecting the current scrolling, cursor position, MaxSearchDistance value). The actual problem with large documents is caused by long execution of the "Highlight word" handler.

I made test build with basic optimization (SendMessage()-calls replaced with SciCall-s to reduce delays) within "Highlight word" handler. Please check it and confirm if the problem resolved.

[ProgerXP]

A reminder for later checking:

• create a file with 150 000 occurrences of the same word on the same line, e.g. foo foo foo foo ... (500+ KiB of text)
• enable highlighting and use default MaxSearchDistance of 96K
• you will notice that scrolling is extremely slow and that not only 96K of the words are highlighted, but all of them (because of the same line?)
• moreover, try to remove all spaces from the buffer (Replace from "space" to "nothing") - you will hear the sound of message box appearing, but the message won't appear and the program will just freeze

[ProgerXP]

The issue described in my post above is definitely present and completely freezes the program if there are so many occurrences of a word on the same line. MaxSearchDistance is certainly not used here.

[cshnik]

Very long lines are not handled properly which caused specified highlighting and some other issues (e.g UI hangs). I've already noticed this in my previous researches. Actually this is not a MaxSearchDistance issue but the result of multiple Scintilla's notifications and heavy/complicated/incorrect? Notepad2e handlers. Here is the typical call stack when using word navigation (Ctrl+Arrow) on a 1MB single line file: Please confirm if we should improve Notepad2e performance for files with such a long lines. big.txt

[ProgerXP]

Please confirm if we should improve Notepad2e performance for files with such a long lines.

Yes, I have also noticed poor performance when trying to work with single-line files (e.g. non-pretty printed JSON) but I've blamed this on Highlight Current Word. I am even used to disabling it to improve performance on such files. Anyway, this should be fixed, I've created a new issue #226.