Multiline selections should be auto-converted Find/Replace in Files

[redmunds]

Multiple line search arguments are allowed for Find/Replace in Files, but they must be in regex format. Since search argument fields are pre-populated from current selection, it would be nice if newlines in selected text were converted to "\n" string instead of just being removed, and also on regex flag is turned on.

Also, we should think of a way to insert newlines via "replace with" text.

For example:

1. Start with this text in page:

   aaa
   bbb
   ccc
   

2. Select range starting with "aaa" and ending with "bbb"

3. Find > Replace in Selected File/Folder

4. The newline is removed from the selelction and the search argument is pre-populated to "aaabbb". Would be nice if the newline was replaced with "\n" so it was "aaa\nbbb". Also, regex flag should be turned on (if not on already)

5. I'd also like to put something like "yyy\nzzz" in the "Replace With" field to have 2 lines inserted.

[TomMalbran]

The search in files doesn't support multiline yet. So I think that that should land before this change.

[peterflynn]

Reviewed. For now, let's just make Find/Replace in Files consistent with simple Find/Replace -- cutting off the prepopulated text at the first newline. Beyond that, we should wait for the full-fledged multi-line search/replace story.

[peterflynn]

Marking 'starter bug' since the bug fix part of this (see previous comment) should be fairly simple. We basically just want the logic in FindReplace.openSearchBar() (where is says "Eliminate newlines") to be shared in FindInFilesUI._showFindBar() so both truncate initialQuery the same way.

[peterflynn]

FBNC @redmunds

[redmunds]

@peterflynn Confirmed that 'starter bug' part works as advertised. Should this issue remain open for remaining work?

[marcelgerber]

@redmunds I don't think so as the remaining part is already a Trello card.

[peterflynn]

Yep -- it's part of the existing Find/Replace: Allow matching across newlines story.

(I know the proposal above includes ways to sidestep around that by converting the user's string into a regexp automatically, but we talked about that in bug review and decided it wasn't worth doing until we get to the full story).