[find-and-replace] Allow more control of searching through the `find-and-replace` service
Have you checked for existing feature requests?
- [x] Completed
Summary
This request came up in discussions.
I can think of a number of reasons that a package might want to programmatically
- reveal the find or project-find dialog,
- fill the “find” text box with a certain value, and
- immediately show the results to the user.
There are ways to do this right now, but they're all hacky and most of them rely on implementation details that they should not rely on.
The find-and-replace package already offers a find-and-replace service, but it's pretty minimal. We should add more methods for the tasks I described — stuff like
type PanelType = 'find' | 'project-find'
type FindAndReplaceService = {
// existing
resultsMarkerLayerForTextEditor(editor: TextEditor): DisplayMarkerLayer
// new…
show(type: PanelType): void
showProjectFind(): void
setValues(
type: PanelType,
values: {
findValue: string,
replaceValue?: string,
glob?: string,
},
options: { autoFind?: boolean }
): void
setFindOptions(
type: PanelType,
options: {
caseInsensitive?: boolean,
regex?: boolean,
onlyInSelection?: boolean,
wholeWord?: boolean
}
): void
}
I think it'd be a bit too far to allow a package to trigger any actions that are potentially destructive (like programmatic “Replace All”) but this should be plenty to start.
Once we add these methods, we'll want to bump the find-and-replace service’s version to 1.0.0. But since none of the existing behavior would change, we'd be able to expose both the new service version and the existing service version at the same endpoint:
{
"providedServices": {
"find-and-replace": {
"description": "Atom's bundled find-and-replace package",
"versions": {
"0.0.1": "provideService",
"1.0.0": "provideService"
}
}
}
}
What benefits does this feature provide?
More of the builtin packages should offer services! It makes the editor more “scriptable” and discourages backdoor methods of accomplishing the same results.
Any alternatives?
As I mention in the discussion topic, there are other ways of doing this, but they are inferior, and they are bound to break if we change any of the implementation details of find-and-replace.
Other examples:
No response
I just realized how similar this sounds to #1269, but they're actually different:
- this ticket is about making it easier to programmatically do things in
find-and-replace’s existing functionality, whereas - #1269 is about making the UI presentation style of
find-and-replacemore generic so that other sources of “results” can use it without having to reimplement everything.
The only similarity they have is that #1269 might add its own methods to the find-and-replace service. But that ticket is much more speculative, whereas this one can be done in a day or two once we get around to it.