Support multi-line search for Global search
sandy081 opened this issue · 46 comments
Support multi-line search for Global search
- Background search implementation for multi-line search
- Adopt results for multi-line. Eg: Matches
- Adopt Replace functionality for multi-line. Eg: Matches
This feature/bug-fix should be prioritized better.
I use global search to find type definitions and make code refactoring decisions based on results, e.g. "find all uses of ..." some particular piece of code.
I've seen, tested, and verified specific scenarios where searching for a search-term using Global Search (with Match Whole Word -on) doesn't turn up a matching result, even though there's a file with that search-term in it. If I open the known file, Global Search will only then start showing the matching result. -- #13068, #9051, #18671
In short, Global Search is a critical feature for helping refactor code, without this improvement I can't trust VS Code search functionality to help me produce quality code. Thanks for the effort. Please get this in.
Komodo edit gets this right, but I'd like to switch to vsc. I use multiple line search/replace in files all the time and vsc should support it.
Currently, VS Code is dependent on ripgrep supporting multiline. If you are interested in this capability, you probably want to follow:
BurntSushi/ripgrep#176
This use case is clearly much more important to vscode than to ripgrep. Perhaps this dependency needs to be reconsidered.
I use multiline/regex frequently in both global and single file searches, mostly for find/replace operations, which forces me to use Dreamweaver to count match instances over 999 or for multiline search and replace when I would prefer being able to just stay in vscode for such things.
I'm not quite sure why VS Code can't just use built-in JS regular expressions for this?
+1 on this, much needed
I have reviewed the project's process documentation, and have found no way to "appeal" an issue's labelling. Given the content of comments here and, especially, the content of the many duplicate issues, I believe this should be labeled bug.
(Yes, I understand it is caused by a dependency, but don't believe that should be relevant to the planning process.)
@gerwitz May I ask which dependency is causing it? Just trying to follow the discussion.
@gerwitz Thanks.
If riggrep will not support this functionality (in a short term), I think just replace it with another tool is the right way.
Speed is not very important for such trivial text manipulation job.
Multi line search / find-n-replace is a must have, imho. Please make it so.
The only reason why I'm still using Sublime Text: Their search input is a multiline text area.
In VSCode when I press shift+enter in the search box, somehow it won't make a new line. I'm not sure why...
The current error message when attempting a multi-line global search is “Literal '\n' not allowed.” I just created #51623 suggesting that VS Code use a clearer error message such as “Literal '\n' currently not supported.”
Please add this.
Multi-line searching is now under development in ripgrep, so perhaps VS Code will be in a position to implement it before too long.
Thanks for pointing that out
I will be thinking about this a bit this month. Ripgrep's work is well-timed since other SearchProviders will soon exist and will also be able to implement multiline search. I will especially focus on UI implications.
How will we display multiline results in the search viewlet?
- We could continue to display one result per line, and only show the first line of the match
- Or we could show tree items with multiple lines of text, and some maximum number of lines (nobody wants to scroll 100 lines past a 100-line result)
We've never had a goal of making the search viewlet the best place to read through all your results. The idea is that users will actually look at file content in the editor and it is optimized with that end in mind. So I would prefer to show single-line results. Possibly with a hint that the result covers multiple lines.
So I would prefer to show single-line results. Possibly with a hint that the result covers multiple lines.
I would prefer single line as a default as well. However, If you do add the ability to show multiple lines, I would rather that be a button toggle or something somewhere on the search viewlet.
When a user does copy all from the context menu. In that case I would want all of the lines.
That helped me:
"search.useRipgrep": false
Now \n is working. Source: https://stackoverflow.com/questions/49942726/visual-studio-code-n-in-regex-file-search-not-supported
@Daijobou Disabling ripgrep allows multiline search only in the tabs you opened, rather than a global search in all the files in the opened directory. The title of this issue is Global search, not just in the files you opened. Nevertheless, this is still faster than manually searching in every single tab if all the files you want to search is opened in the editor and the search term is the same
just try this today, previously using atom
now is time to back to atom
see you when it support multiple line search
bye
I can't believe this isn't a thing yet, I just spent a ton of time trying to figure out why it wasn't working only to find out it's not possible yet.
Sublime Text supports this perfectly, and it's extremely useful (necessary even) when moving large amounts of data from one format to another.
Looking forward to this being added to VSCode too.
I would like this feature too. I bought TextCrawler Pro for this (long ago). :)
@klepon I like then people are threatening they will use another tool, it's very funny 😄 Just try to realize you're using a free tool from Microsoft with such great features and amazing support for almost all programming languages. Instead of help and motivation for the team, you're spreading the negative and toxic things around this community instead of supporting each other. If you think this is very easy to develop such features into existing tool with such large codebase then why you're not creating a PR by yourself since you're paying zero money to use it...
The only reason I pull up NotePad++ anymore instead of using VS Code for most things all seem to be related to search. NP++ allows for multiline search and replace and I use it a great deal.
libripgrep team closed their issue on August 20. Looks like it was fixed in this PR: BurntSushi/ripgrep#1017
When will we be able to see this in vsc?
@winzig Give it time. I supposed this will be in for the next major version release, as this is quite a big change.
@winzig Give it time. I supposed this will be in for the next major version release, as this is quite a big change.
They haven't added it to the backlog yet. I don't think they plan on adding it (correct me if I overlooked something).
They haven't added it to the backlog yet. I don't think they plan on adding it (correct me if I overlooked something).
Oh, weird. Why haven't they added it to the backlog yet?
I think it is a unnecessary feature
If this is closed, where can we find more information about the solution?
@OliverJAsh it was just closed today so please be patient for a few days. I'm sure it'll be added to the release notes of a next release of VSCode.
🤗
I mean, you can see it's closed because code was committed, and as if that wasn't enough it was added to the October 2018 milestone, which may hint that perhaps we'll see this in the October release (which means early November).
I tweeted the documentation 🐦
https://twitter.com/roblourens/status/1049866207292088321
It's in Insiders now. You can search in multiline mode if you explicitly include a \n in your regex, same as in the editor.
Multiline matches include a UI hint that the match includes more lines, in the form of e.g. +3 if the match is 4 lines long.
@roblourens Would it differentiate between \r\n, \n, and \n\r if you only specify \n?
You can checkout this: https://marketplace.visualstudio.com/items?itemName=axlan.multiline-find-and-replace It allows you to copy the formatted multi line regexp.
I also noticed that you cannot do multiline regex searches via the GLOBAL SEARCH bar -> It prints an error saying 'Literal \n currently not supported'
That issue is fixed in insiders @gsrafael01