DOUBLE (edit: was REMOVE) the line-length limit in Find-result window

[sasumner]

Description of the Issue

There has been a complaint about long lines not being "well-represented" in the Find result window. See https://notepad-plus-plus.org/community/topic/18028/how-do-i-see-the-full-line-in-find-results-window.

Long lines are truncated and an ellipsis appended if the line is too long. If the "hit" for the line occurs in the truncated part, the hit marking is either not present, or is sometimes put in a questionable location.

The line-length limit is represented by SC_SEARCHRESULT_LINEBUFFERMAXLENGTH which resolves to 1024. This #define comes from a Scintilla #include but there doesn't seem to be any rationale for it; perhaps it is a vestige from the early days?

Removing the line-length limit would solve the problem, but would it create any new problems?

Steps to Reproduce the Issue

See the Community issue linked earlier.

Expected Behavior

Hits beyond column (roughly) 1024 should have their matched hit-text fully visible in the Find-result window.

Actual Behavior

Lines with length greater than (roughly) 1024 are truncated and a ... is appended to the end. Thus, the true hit text is not knowable from simply looking at the line in Find-result. Note that if one double-clicks the line in Find-result, the true hit-text will be revealed because the user's caret selection will indicate it in an editor tab.

Debug Information

Notepad++ v7.8 (32-bit)
Build time : Oct 7 2019 - 00:58:16
Path : C:........\npp.7.8.bin\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 1709
OS Build : 16299.1508
Plugins : ColumnTools.dll Explorer.dll LocationNavigate.dll MarkdownViewerPlusPlus.dll mimeTools.dll NppConverter.dll NppExec.dll NppExport.dll PythonScript.dll

[sasumner]

Just making some notes here:

There's some code in a case ProcessFindAll block that looks like this:

TCHAR lineBuf[1024];
if (nbChar > 1024 - 3)
	lend = lstart + 1020;

This looks suspiciously like it is trying to work with the earlier mentioned length limit, but instead of using the #define for SC_SEARCHRESULT_LINEBUFFERMAXLENGTH it is using the magic number of 1024.

Also the - 3 part is also reminding me of the length of "..."

If this is truly what this code is doing, there are certainly better ways of expressing it.

[devilmanzato]

This length search line limitation is very frustrating, it impairs the usage of the program for a lot of my use cases.

[sasumner]

Additional discussion is found here: https://community.notepad-plus-plus.org/topic/18798/increase-search-results-line-length

It discusses @devilmanzato 's use case, which he neglected to put here, which could be of some importance.

[Rovastar]

I too would like to see this. I often work with lines longer than a thousand characters and use search extensively (It is my main use case for notepad++).

[fhsdjk]

Could it be that this issue is closed because #8256, and #8256 is closed because of this?

[sasumner]

This issue is currently Open.

[fhsdjk]

Argh, sorry, mixed it up :(

[donho]

SC_SEARCHRESULT_LINEBUFFERMAXLENGTH is a constant used only in Notepad++ for Search result lexer:

notepad-plus-plus/scintilla/lexers/LexSearchResult.cxx

Line 102 in 814ecd2

char lineBuffer[SC_SEARCHRESULT_LINEBUFFERMAXLENGTH];

Which value do you suggest to increase to?
I'm not against increase this value. OTOH, we need to recompile both notepad++.exe and SciLexer.dll.

[sasumner]

@donho said:

Which value do you suggest to increase to? I'm not against increase this value

Hmmm. Well, there was a suggestion here #9014 (comment) for ~2K wide characters or ~8K utf8 bytes...
I would say 2K makes sense, currently.

OTOH, we need to recompile both notepad++.exe and SciLexer.dll.

There are some good reasons pending for a Scintilla update within N++.
However, currently there are a few that are still evolving/maturing (boost regex related).
I started some notes on an update to 4.44 here: #8900

[donho]

2K makes sense, currently.

OK - 2048 sounds reasonable to me too.
Do you wanna take in charge of it?

I started some notes on an update to 4.44 here: #8900

OK, thank you @sasumner

[sasumner]

Do you wanna take in charge of it?

OK, I will.

[sasumner]

So here are two very-relevant comments about the untruncated line-length limit in Find result window:

• Fix find result line length #9014 (comment)

• Fix find result line length #9014 (comment)

But...proceeding ahead with a new constant defined as 2048 for SC_SEARCHRESULT_LINEBUFFERMAXLENGTH for this issue...

[aritchie-io]

How about another solution - even if you don't show all of the matched line in the search window results, why don't you have an option to select all the 'original' lines from the file that correspond to the found lines instead of, or in addition to, selecting the lines in the search window?

I am working with a file that has 2500 line lengths so even extending the limit to 2048 will not help me. I understand that there is maybe a performance consideration here but if you are able to take the list of line numbers associated to those found lines and then select/copy those lines in the file then this would handle any line length.

[alankilborn]

@aritchie-io said:

How about another solution

Here's one, presented as a demo where we want the text of all lines in a file containing the word fix:

1. Open Notepad++'s change.log file
2. Open the Mark window (by pressing Ctrl+m)
3. Set Find what to (?-s)^.*fix.*
4. Set Wrap around to checked
5. Set Search mode to Regular expression
6. Press the Mark All button to see:
   
7. Press the Copy Marked Text button
8. Do a paste (Ctrl+v) in some other file tab, where you'll have: