Populate "Find in Files" - Result Window

Alan Kilborn

Somewhat unfortunately, there is no actual plugin api for Search results.
So you’d have to do things very manually – read “hackishly”.
I’d say it is “possible” but not “easy”.

An especially challenging part might be mimicking the highlighting of match positions within the lines. This involves specifying positions for the lexer (a bit tedious and difficult in itself), and not all of the data is in the Search results window (example: if real Find in Files matches over more than one line, only the first line of that match is shown, but yet if you double-click it, it highlights the entire match covering 2+ lines – it does this because Notepad++ itself – not the results window – holds that sort of “extra” information in its own data structures).

So I think the bottom line might be, you’d have to intercept all possible user interactions with the Search results window, decide if it is you that need to process it (because it is one of your “special” entries) or if you should leave it alone and pass things to Notepad++ to deal with (because it is just a standard results entry interaction).

I think I can see the way to do this, and you may have inspired me (big maybe!), but this would not be an undertaking for the feint of heart. :-)

Alan Kilborn

@Alan-Kilborn said:

I think I can see the way to do this

After some more thinking on it, I believe it all works EXCEPT for one thing, which kills it all: The aforementioned “specifying positions for the lexer” part.

What Notepad++ does is to maintain a data structure with one entry per line of (the entire) Search results. This is what Notepad++ uses to hand off to Lexilla in order to highlight the matches from a search.

The “one entry per line” is the problem for something else besides Notepad++ core writing into the Search results area – it would mess up the data structure because Notepad++ wouldn’t know about lines added by something else. Bottom line is Notepad++ (and thus the lexer) would think there is N lines in Search results, when maybe there is really M lines there (M > N). The end result would be, well, a mess.

I suppose the only recourse left would be a “feature request” to allow plugins to contribute to the Search results window (and thus Notepad++ could know how to properly formulate data for the lexer), but I wouldn’t count on such a feature request being implemented.

Another approach, @R0binBl00d , would be to write data that looks like Search results data into an editor tab. I’ve done this with some success in scripts that I’ve written.

Mark Olson

Why not just use a TreeView type control? In C# you can use TreeView and I’ve been very satisfied with that, but there are various C++ plugins like JSON Viewer that use similar controls.

Ekopalypse

@R0binBl00d

as Alan already wrote, it’s not a good idea to rely on Npp’s internal non-public data structure, that screams problems in the future.
If you want something similar with your own scintilla control, without writing a lexer that does the coloring, you can use SCI_ADDSTYLEDTEXT which basically means you iterate the bytes of the string and create a new string where the even byte is the style byte.

Pseudo code

    style_id = 1
    new_content = ""
    for i,c in "Hello"
        new_content[i*2] = c
        new_content[((i*2)+1)] = style_id

R0binBl00d

@Ekopalypse @Mark-Olson thanks for the Input,
I could just replace my existing RichtextBox from my PopUp with a TreeView, ListView or with something else, but this approuch completely destroys the “Look&Feel” of using Notepad++

the goal was to use an existing infrastructure with known behaviours, like double-click a line in the result-view and have the file beeing processed by my plugin and opened at the specific occurance in that file.

@Alan-Kilborn " […] there is no actual plugin api for Search results […]
really unfortunate, maybe we should request this as a feature.

I could think of a lot of different Use-Cases for this:

Talking about the JSON-Viewer earlier:
Instead of giving us a PopUp that the JSON is faulty, he could give you a “search-result” with the position and context where the error occured.

So this Search results-API could also be used as an “Error List” (analog to the one in Visual Studio)

or a “Call Stack”, “Find Results”, “References Window”, etc.
All of them show some information related to a Textfile. If you doubleclick an entry he opens the file at that position.

@Alan-Kilborn said in Populate "Find in Files" - Result Window:

you may have inspired me

wouldn’t mind if you file the “feature request” maybe with your reputation it’s more likely to get attention ;-)

Thanks a lot to all of you.

Alan Kilborn

@Ekopalypse said:

…you can use SCI_ADDSTYLEDTEXT…

Or even indicators could be used. I’ve wondered a time or two why Notepad++ didn’t use indicators to highlight matches in Search results instead of lexing. Maybe at the time, lexing was to “cool” thing to do.

for i,c in “Hello”

This pseudocode may leave some scratching their head.
i here is meant as an index to a character in a string; c is the character itself.
The pseudocode here is very much like Python, so a real Python version of this line would be for i,c in enumerate("Hello"):

Ekopalypse

@Alan-Kilborn said in Populate "Find in Files" - Result Window:

Or even indicators could be used.

If coloring is the goal, then indicators can also be a solution, yes.

I’ve wondered a time or two why Notepad++ didn’t use indicator

Because of the SCI_STYLESETHOTSPOT I suppose.
If you want a clickable thing, indicators are not as good as styles.

This pseudocode may leave some scratching their head.

I can’t imagine anyone developing a plugin having a problem with this pythonic pseudocode, to be honest. :-D

@R0binBl00d - if you want something that fits nicely into the npp look and feel, I would use a scintilla control in your dialog and replicate what the search results dialog does.

Alan Kilborn

@Ekopalypse said in Populate "Find in Files" - Result Window:

If you want a clickable thing, indicators are not as good as styles

The hit markings in Search results are not “clickable things”, in the sense that they do something when clicked. Double-clicking causes their parent window to do an action: jump to the source line in the editor window.

I can’t imagine anyone developing a plugin having a problem with this pythonic pseudocode

I was thinking more of the casual reader…but probably the casual reader has stopped reading this topic much earlier. :-)
And truly, before I was exposed to Python, I would not have known what this pseudocode meant, and I know several languages well.

if you want something that fits nicely into the npp look and feel, I would use a scintilla control in your dialog and replicate what the search results dialog does

Yes, this is the obvious thing; unfortunately, it takes extra screen space to display (in contrast to it being possible to share the same space as Search results.

Ekopalypse

@Alan-Kilborn said in Populate "Find in Files" - Result Window:

@Ekopalypse said in Populate "Find in Files" - Result Window:

The hit markings in Search results are not “clickable things”, in the sense that they do something when clicked. Double-clicking causes their parent window to do an action: jump to the source line in the editor window.

that shows how often I actually use the search results window, actually never :-D

Yes, this is the obvious thing; unfortunately, it takes extra screen space to display (in contrast to it being possible to share the same space as Search results.

Unless it is placed in the same docking area as the search result. But then, of course, I have to access the respective content via tabs.

PeterJones

(I am not sure if @Ekopalypse or @Alan-Kilborn noticed, but @R0binBl00d had a post which was held in the post queue for a few hours, so it suddenly appeared in the middle of the conversation, but happened after more posts had been made, so it might have not been noticed, even with notifications of the reply)

@R0binBl00d ,

there is no actual plugin api for Search results […]

really unfortunate, maybe we should request this as a feature.

My guess is that it would be rejected out-of-hand, as Don probably doesn’t want plugins touching something as integral to Notepad++ as the Search Results window (he doesn’t give access to most of the panels, whether it be FunctionList or Project or FaW or Search Results or …).

or a “Call Stack”, “Find Results”, “References Window”, etc.

Correct me if I’m wrong, but I thought the Function List already was a TreeView, so I’m not sure why things like a “Call Stack” or “References Window” couldn’t be implemented as a TreeView (and, in fact, I am guessing that’s how @Ekopalypse’s LSP “Symbols” window is implemented), because tools like that, implemented as docking panels in other plugins, already do “feel” native to me, and work as I expect

you may have inspired me

wouldn’t mind if you file the “feature request” maybe with your reputation it’s more likely to get attention ;-)

@Alan-Kilborn can obviously reply for himself (once he notices your post), but my guess is you’ve inspired him to a PythonScript plugin solution, rather than to put in the feature request.

And actually, Don tends to dismiss feature requests from the “forum power users” even more than his dismisses/ignores requests from “normal users” like you.

If you put in such a request, and Don indicated that it’s interesting but he doesn’t have time, then I am surmising that Alan would be willing to convert such a script into actual Notepad++ code (assuming he can figure it out), but that he wouldn’t want to start on such an activity until Don gave his buy-in, because Don has quashed large-effort PR submissions when the requestor didn’t get his approval before working on it, and no one likes wasting their effort. (But, again, I may have missed my guess on Alan’s inspiration and/or willingness, and it’s quite possible I’ve missed my guess on whether Don would want to work on such a feature himself.)

But I would request, if you’re going to bother putting in the Feature Request Issue, you could focus on the “please give us an API for Search Results”, but it would be nice if you said, “and, if possible, the other panels, like Projects, FaW, FunctionList, Document List, and the like” – because really, all of those panels could be useful to plugins, for adding functionality to the existing interface or for using the existing interface to supply results in a way that Notepad++ users are already used to.

Ekopalypse

@PeterJones said in Populate "Find in Files" - Result Window:

couldn’t be implemented as a TreeView (and, in fact, I am guessing that’s how @Ekopalypse’s LSP “Symbols” window is

No, all my docking dialogs are made from Scintilla controls.

Alan Kilborn

@PeterJones said:

Alan can obviously reply for himself (once he notices your post), but my guess is you’ve inspired him to a PythonScript plugin solution

Even scripting can’t help here, in order to add custom items to Search results, due to the lexing problem I mentioned earlier.

PeterJones

… and there’s 2 of my 3 guesses shot down. So that means Don is going to accept the issue/PR without hassle, right? that way, I’m 3/3?!