Improve search results tab
Open, Needs TriagePublic

Description

Ideas:

  • display results for each matching line like in mc:

  • display file content for selected result (and mark the matching lines)

mockup:

janlepper updated the task description. (Show Details)Jan 11 2017, 4:40 PM
janlepper updated the task description. (Show Details)Jan 11 2017, 4:56 PM
abika added a subscriber: abika.Jan 11 2017, 5:30 PM

Great! Nice feature. Is that KWrite from KParts?

janlepper updated the task description. (Show Details)Jan 12 2017, 1:16 PM

I'm sorry - it's just a mockup ;)
I don't think I'll be working on this in the near future - just wanted to collect some ideas.
The mc-like result list will probably require a lot of work - in KrView there is a 1:1 relationship between view item and a file, but this would require multiple items per file.

when it's a mockup I would suggest to have an overview on the right where you see the results in the file.

How about that?

palant added a subscriber: palant.EditedFeb 3 2017, 12:35 PM

This mockup is great but implementation will certainly take time. Unless somebody plans to work on this really soon, maybe a simpler solution is worth considering: when opening the viewer from the file search with non-empty text, do a search for this text in the viewer automatically. So the first result line should be selected immediately and pressing F3 should bring up the other matches. That's what Total Commander does. These proposals aren't mutually exclusive of course.

asensi added a subscriber: asensi.Feb 5 2017, 6:25 PM

This mockup is great but implementation will certainly take time. Unless somebody plans to work on this really soon, maybe a simpler solution
is worth considering: when opening the viewer from the file search with non-empty text, do a search for this text in the viewer automatically.
So the first result line should be selected immediately and pressing F3 should bring up the other matches. That's what Total Commander does.
These proposals aren't mutually exclusive of course.

I agree :-)

True, that would be easier and also do the job.
KParts::TextExtension should come in handy here.

palant added a comment.Feb 7 2017, 2:27 PM

KParts::TextExtension would have been too easy. At least on my system both viewer and editor are using KTextEditor which currently doesn't appear to implement KParts::TextExtension. It implements its own KTextEditor::Document interface instead which also allows searching but requires introducing a new dependency (not to mention fallback code). I am trying to make it work.

palant added a comment.Feb 8 2017, 9:51 AM

Well, I'm stuck. The way I see it, the searchText method of KTextEditor::Document merely gives you the search results but doesn't affect the UI. There doesn't seem to be a way to manipulate the search bar, in particular the method KateSearchBar::setSearchPattern() is only called by unit tests.

Another option: Use Lister and add the necessary methods.

palant added a comment.Feb 8 2017, 4:04 PM

Sure, that would be easy - but there is little point as long as Lister isn't the default.

Well, you could add
static void KViewer::viewWithLister(QUrl url, QString searchText)

palant added a comment.Mar 6 2017, 8:40 AM

Yes, I meant that it won't benefit too many people as long as the default viewer isn't the lister.

Right, I didn't really think this through.
So it's probably the lesser effort to embed Lister into the result view.