Only show a limited and trimmed range in upper view for long lines

[pintassilgo]

Sometimes I need to search in files with long lines, then FiF lists results showing the entire line for each match. This defeats the purpose of the plugin for me, which is a list summarizing each result.

1. I suggest a way/option so that results are listed one per line, without wrapping long lines, preferably with the searched word/string centered to provide better context.

2. Other improvement in this regard would be an option to trim indentation in this upper view, because this blank space on left would be better used to display more text for the user to have more context.

3. Moved to Highlight all matches #81.

[Alexey-T]

(please let me know if it's better to make a new issue for each thing)

New issue for that - will be better.

[Alexey-T]

I suggest a way/option so that results are listed one per line

FIF4 in the '=' button has some options. did you try them all? see the bottom part of '=' menu:

• show relative paths
• results tree >>

[pintassilgo]

FIF4 in the '=' button has some options. did you try them all? see the bottom part of '=' menu:

* show relative paths

* results tree >>

Thanks for replying, but none of this relates to what I requested. FiF always displays full and wrapped lines, I don't see any option to change this.

[Alexey-T]

Can you give the patch with the option? option must be Off by default.

[pintassilgo]

To better understand how this issue is relevant, I'll show the same example comparing Notepad++ (good) and Cuda FiF (need to be fixed):

Notepad++:

Cuda FiF:

Can you see? Notepad++ lists (bottom view) one result per line. If you want to see more context for any of it, you click one of them and document will be scrolled to it.

In Cuda (upper view), on the other hand, you can see only one result because the wrapped line is filling all the space. This defeats the purpose of the plugin when you're searching in a single file. The experience in this case is similar to using default Cuda find, without showing multiple matches in the screen so there's no reason for the split view.

[Alexey-T]

FIF4 last is 4.8.15, but your screenshot - 4.8.12.

I will look why word-wrap is On for you. for me - it is Off. check it on last version. I don't understand why it is on or off.

[pintassilgo]

Updated, but still wrapped. Probably because I use line wrap by default ("wrap_mode": 1,). This FIF dialog should have word wrap forced disabled for upper view.

[Alexey-T]

Yes, wrap-mode is got from user.json. It must be easy to fix it, I will try.

[Alexey-T]

do you suggest to hardcode wrap=Off for both editors (upper/lower)? for upper only?

[pintassilgo]

Upper only. Later, after #82 is merged, I will have only upper editor in bottom panel of main window (similar to my Notepad++ screenshot). The lower editor isn't needed.

[Alexey-T]

Fix made, only in Git. the proper release will be much later, after next fixes.

[Alexey-T]

If this issue is solved, pls close. other 2 issues should be in separate GH issues.

[pintassilgo]

Thanks.

While it's already much better now, I suggest to keep this open because it can still be improved as the fix wasn't exactly was I suggested.

What code current does is to show the entire line. What I suggested and still think it would be much better is to display only the "visible range", so that you can also see the matches in other lines.

Think of a file with 3 lines, each one with 10k chars. The first line has the word "test" at the start. The second line has the word "test" at the middle of the line. And the third line has the word "test" at the end. If you run FiF searching for "test", you will only see the word for the current match. Example:

I suggest to, instead of showing the entire line, to get a small range surrounding the match.
For instance, for the first line the range would be from column 1 to column 100. For the second line, the displayed text would be the range from col 5001 to 5100 (supposing the "test" word is in there). And for the third line it will extract from col 9901 to 10000.

This is specially important if you're dealing with minified big file. With Current FiF, the entire file (which is a single line) is printed multiple times in the view, wasting memory and maybe causing slowness.

A further improvement for a different case would be to minify the range to a single line to give better context for formatted code. Example:

return editor(
  name='Cuda',
  version='1.214.2.0',
  buildtype='qt5-x64'
)

If I search for Cuda, current FiF displays only name='Cuda',, which can be too vague to understand. With the range thing, FiF could display something like:

return editor( / name='Cuda', / version='1.214.2.0', / buildtype='qt5-x64' / )`

This gives more context/info for the user about the match.

[Alexey-T]

Good suggestion! I don't know how to do it... will ask Kvichans and study it.