Search results as text

[jchavarri]

Hi! 👋 I have started using Atom lately, and I love it :) but I was missing this feature so much, so taking a stab at building it here.

Description of the Change

Adds a new class ResultsTextViewManager that uses TextEditor in order to show the results as text.

It is heavily influenced by Sublime Text search results. At this point, it features:

• Shows the results as text, showing file paths, and line numbers for each result
• Merges results that are on the same line for a more continuous view
• Configurable number of lines before and after result via the already existing searchContextLineCountBefore and searchContextLineCountAfter
• Double click on a result line to open the result file at that specific line
• Un-intrusive, "opt-in" configuration via a newly added find-and-replace.findResultsAsText config key
• A grammar created "on the fly" to highlight file paths and line numbers
• The search results pane gets the right mag icon + title
• Uses shouldPromptToSave to not prompt the user when closing the search results pane

Alternate Designs

Disclaimer: I have no experience developing Atom plugins or with the Atom codebase at all 😁 so there is probably plenty of room for improvement.

I tried to not touch the existing ResultsModel, and just add any needed modifications on the text output at the "rendering" step (i.e. just before setting the text on the TextEditor instance). I also tried to not subclass TextEditor as there seems to be a lot of logic relying on that class that might fail when subclassing.

Benefits

The main benefit of implementing the results as text with an "opt in" approach is that users that are used to the existing web based results pane won't see any changes.

The benefits of having results as text are mainly:

• Use buffer search to search on the results (aka "Searchception")
• Copy text from the results
• Save the results in a text file

Possible Drawbacks

I don't see any 🤔 I was expecting to see performance issues but it seems to be as performant as the web based search results, at least on a first look (would need to test more thoroughly).

Applicable Issues

#133 Search in search results. Searcheption
#765 Select and edit search results as text

Also related: https://discuss.atom.io/t/searchception-missing/1779/3.

Todo

• Add more tests
• Add a separate set of markers for the project results to keep highlighting them in case a buffer search starts (right now, the buffer search takes over any existing markers)
• “Progressive” results that appear while searching (i.e. use onDidSearchPaths)
• Add other listeners: onDidClear, onDidClearReplacementState, onDidErrorForPath... it's still unclear to me what they do, will have to take a deeper look.
• Hide gutter lines: I wasn't able to override the user setting
• Open files with pending on double click
• Use projectSearchResultsPaneSplitDirection when opening files on double click (not sure what this config does).
• Fix a bug where the grammar won't be applied correctly when searching for a second time with the same query string as the first time, after closing the search results pane
• Fix a bug where when reopening Atom, an orphan untitled pane opens on launch if the Project Find Results pane was being shown before closing.

Status / questions

Even if this PR is clearly not ready to merge, I would really appreciate a first review or some pointers from the maintainers about the general strategy. Some other questions I have –and wasn't able to find answers to– are:

• ES6 vs Coffeescript: I am assuming that ES6 is the right choice due to the most recent files using it, is that correct?
• How does one enable ES6 linting in Atom when working with the find-and-replace project? There doesn't seem to be any .eslintrc file or package.json config.

Thanks!

[winstliu]

Disclaimer: Any comments I make do not mean that I will be the one reviewing and merging this PR. Just trying to be helpful.

• ES6 is correct. A gradual migration is in progress from Coffeescript to JavaScript.
• I'm not sure on linting. Some projects are using a custom ESLint config, some are using Standard, and some are using eslint-config-fbjs-opensource. I don't think a consensus has been reached yet, but Standard seems like a safe bet in the interim.