Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

expose doSearch for extensions #7445

Closed
wants to merge 1 commit into from
Closed

expose doSearch for extensions #7445

wants to merge 1 commit into from

Conversation

zaggino
Copy link
Contributor

@zaggino zaggino commented Apr 8, 2014

ping @TomMalbran - i'd really like to use this to search for Git merge conflicts in a current project

throw new Error("RegExp query is required");
}
return _doSearch(query.toString(), getCandidateFiles(), query);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bunch of the search options are globals in the module, so the behavior in terms of what gets used will be awfuly inconsistent:

  • Case-sensitive & regexp settings will be ignored (since this API always passes in its own regexp)
  • It will use whatever exclusion filter was in place the last time a search was run, since it's initialized in the Enter-key handler
  • It will use whatever subtree scope was in place the last time the search bar was open (even if it was canceled, unlike previous bullet), since that's initialized in _doFindInFiles()

Actually, looking at what else _doFindInFiles() does, it appears that this function would break pretty badly if an existing set of search results was still visible in the bottom panel.

Overall it seems like to expose this in a reliable way we'd need to rework how state is stored in this module to be more compartmentalized. Doable, and a worthwhile cleanup anyway, but it requires much further-reaching code changes...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll work on this little later and ping you for review @peterflynn

Do you think it'd be better to pass some kind of state object between functions or is there a cleaner solution when passing around too many variables?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting the methods directly on some sort of state object would be another option potentially...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A search class might be the best solution. We could export it and you can
even extend it to change what you don't want.

I actually did something similar but just for the results to be able to
share code between the find in files results and the replace all. But then
I figured that an easier solution would be to place a replace input and
button in the find in files results and make the replace all command
execute a find in file. This would also just work for replace in files.

@zaggino zaggino self-assigned this Apr 9, 2014
@zaggino
Copy link
Contributor Author

zaggino commented Apr 9, 2014

Assign to myself and leaving open as reminder - I'll try to rewrite the code to use some kind of search class when I'll have the time. (If nobody will do that before me)

@njx
Copy link
Contributor

njx commented Apr 23, 2014

FYI - haven't thought this through, but if we're doing refactoring in Find in Files, we should consider how it might affect how we fix #6966 and the other PR referenced above (#7512).

@zaggino
Copy link
Contributor Author

zaggino commented Apr 23, 2014

Well I honestly don't have time to do this anytime soon right now.

@njx
Copy link
Contributor

njx commented Apr 23, 2014

Yup, just noting this here so that we remember to think about this case if we end up refactoring it for any of the other cases.

@njx
Copy link
Contributor

njx commented Apr 28, 2014

FYI, I'm currently planning to start doing some refactoring in the Find code in order to support the Replace Across Files feature.

The first step is going to be to unify the FindReplace and FindInFiles input UIs, and I was planning to do that by separating out the find bar UI code entirely from those two modules, making the search code completely headless. (It won't be totally UI-free yet, because the FindReplace code will still interact with the editor and the FindInFiles code will still own the results panel at this stage, but it will at least be free of any UI code related to the find bar.)

That's still probably not enough for what you want here because we'd also need to decouple the Find in Files engine from the results UI, but that's likely to happen in a later phase, where we generalize the current single-file Replace All feature to support Replace Across Files (which will probably involve unifying the Replace All panel with the Find in Files results panel, I think; I haven't looked at those parts of the code in detail yet to know if that makes sense, though).

I'll keep in mind your use case here as that code evolves, and at some point might ping you to make sure it's going in the right direction for what you need.

@njx
Copy link
Contributor

njx commented May 14, 2014

@zaggino - I've done a lot of refactoring in the nj/replace-on-disk branch that should help with what you want here. In particular, you should now be able to call FindInFilesUI.searchAndShowResults() in that branch and pass it all the info about the query you want to run (including whether it's a regexp, filter, scope, etc.). It will take care of properly resetting the state of the find engine, and it won't disturb the existing saved toggle state of the regexp/case sensitivity buttons in the find bar, I think. Could you take a look at that branch and see if it does what you want?

I'm going to close this since that refactoring should be the right path forward - if you need more changes let me know. Thanks.

@njx njx closed this May 14, 2014
@njx
Copy link
Contributor

njx commented May 14, 2014

(Note that in your case, it's probably as simple as FindInFilesUI.searchAndShowResults({query: /some regexp/, isRegexp: true}) (assuming you wanted to pass a regexp). If it's just a string, it's even simpler: just pass {query: "some string"}.

@zaggino zaggino deleted the zaggino/doSearch branch May 15, 2014 00:12
@zaggino
Copy link
Contributor Author

zaggino commented May 15, 2014

Thanks @njx - I'll look at it later when'll have some time on my hands.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants