Search and Replace

Facility for finding text and replacing it with something else.

Goals

Find is primary, replace is secondary.
Focus on the the current document as the primarily initial scope of searches. Project-wide searches should be secondary.
Easy identification of the text that is being searched for, possibly amongst a large number of matching search results.
Allow returning to the original position in the document after conducting a search?
Implement core search & replace functionality found in other editors (notable gedit)
Allow using glob match or similar
Allow setting case-sensitivity, regex, etc

Plans

This likely involves porting gedit's search/replace to Builder. Most of the details are implemented in GtkSourceView anyway, and are easily reusable.

We also need to add a right-click context menu to the search entry (ctrl+f or / in vim mode) to allow toggling case-sensitivity.

Relevant Art

Xcode

Treats finding in file and searching project-wide as separate UIs:

More details.

Atom

Sublime Text

Discussion

One common behavior is to search for a term that is known to be near the actual target.
Useful bits of context when trying to identify the target of a search:
- What the search target is - is it a function, variable, etc?
- Position in the symbol tree - what does it belong to?
- Nearby text.
A particular challenge - dealing with lots of matching terms, potentially close to oneanother. Typical approach of using prev/next to browse results can be labor intensive.
It's worth considering the interaction with scrolling and minimaps - identifying search results in the scroll bar trough, or skipping through groups of search matches somehow.

Initial Design Experiment

Most IDEs use a fairly standard approach to find/replace - they show a bar or small drop down, like in Xcode or Atom. This approach has some advantages. In particular, it allows you to view search matches in place, so you can tell whether it is the item you are looking for.

However, there are some issues with it:

When there are large numbers of results, it is extremely hard to browse using next/previous buttons. This is a particular issue when results are clustered close to each other - clicking through them to the next group is totally painful.
You have to hunt to to see where results are in the symbol tree.
There's no way to see if there results in other files (this is particularly useful if there aren't any hits for the current file.
Since the only way to view results is to scroll to them, it is easy to get lost. This is made worse by the fact that there's no way to return to your original point in the document.

This design attempts to resolve these issues. However, there are some issues with it:

Project-wide find is essentially part of global search - it belongs to a different feature set. You really need to be able to open individual documents from the search when searching across the project.
Replacing inside a document, it is helpful to see each search match in context. You lose that.

Tentative Design

Project-wide find/replace can be treated as a non-essential secondary feature.

TODO list

Assignee: MatthewLeeds

☑ Create an XML version of Allan's mock-up and test it in Builder

☑ Connect the existing replace functionality to the new UI

☑ Allow case sensitivity

☑ Allow whole word matching

☑ Allow regular expressions

☑ Make the 'c' option on the vim substitute command trigger the search-and-replace UI

☑ Add a squiggly underline when the search or replace regex is invalid

☐ Allow search or replace to be limited to a range

? Allow project-wide replace