Feature request: 'Ignore comments' checkbox in the 'Find' dialog

[thorn0]

Wide popularity of the embedded documentation conventions like JSDoc and C#'s XML comments leads to a situation where comments often constitute the bigger part of a source file (e.g. look at the source of angular.js: the whole API documentation is there!). This abundance of comments makes it extremely difficult to find anything in the source code proper. For example, reading someone's code, we might want to know how and where a certain function is used. However, if we decide to conduct a search by its name, we might get lost in dozens of code samples in the comments and overlook some important case of its real usage. Shift-F12 often helps in such situations, but not always. This undermines the habitual workflow of those who are used to rely a lot on the search to read the code. Not sure if any other editor has this feature, but it would be great to have the 'Ignore comments' option in VS Code's search dialog.

[hashhar]

Is there any way to get the list of comment tokens from all the grammar's (including extensions) installed in vscode?

I think this will become just a matter of using a strong default regex to exclude comments. I can try and implement this.

[nadrane]

Any news on this feature request?

[rebornix]

I'll take a look at this feature once I finish the enhancement of Find Widget. It's a valid feature request. The only technical problem we need to solve is actually detecting comment area.

[hashhar]

@rebornix A better way could be to allow the language extension authors to implement this. Most language extensions perform some parsing and hence can figure out what the comment area is. Will need a new API in VSCode to be able to plug into it.

It also helps to future proof the implementation and that way it will work for all other languages which have a method of parsing.

[mustafaabobakr]

Any news on this feature !!?

[LeThiHyVong]

Any news on this feature request?

[nicothed]

I'm starting to wonder if anyone really uses VS Code... Webstorm has it and I use it all the time. As soon as you have a mid size project, this is a must have!

[SVNKR]

Is there any progress going on with this feature request? Its a MUST-HAVE as the only way around is using regex, which is a painful way wrt simpler ways like a checkbox of ignore comments.

[rebornix]

As I mentioned above, this is an interesting feature which takes syntax into account for both find widget and search viewlet. WebStorm puts this feature in a filter dropdown list

We don't necessarily need to make it an UI element but a setting where users can control whether to filter out string or comments while searching. The challenge here is we are making search/find language agnostic. Currently we rely on TextMate to do the tokenization, whose most grammars are complex and beautiful but not fast enough for simple searches. When we consider sementic highlighting, we can probably think about this feature as well. The language service provides ranges for comments and strings real quick and then we can quickly filter them out.

The same technique can be used for spell checker as well, but again, relies on a fast tokenizer.

cc @roblourens

[papb]

It would be great if this was added to some milestone 😬

[sirmspencer]

Also include "Only comments" option

[abhishekdgeek]

Please add search in comments along with search everything but comments. Missing IntelliJ Idea today.

[WORMSS]

So is this even going to be a thing or is it something Microsoft is going to do as a wont-fix ??
It's been 3 years, with multiple people requesting it, but this is the only thing that is not "closed"

[azenapow]

I hope this features.

[aaron-oxford]

4 years and no response... Is there an extension that can add this feature?

[techieshark]

Possibly useful but not nearly as simple as requested feature https://github.com/nikaspran/vscode-ast-query (uses syntax from https://github.com/estools/esquery )

[teneon]

I am looking for this feature as well. Trying to exclude comments in the search results (ctrl + shift + f), but this option doesn't seem to be available yet. Would be great if we could get it :D

[samithar]

Hi Team, is this going to be a feature ever? Would very much like it :) Thanks and keep up the hard work

[cape-]

Hello VS team! Please consider this feature, is really unfriendly to have to manually check match by match.
Thank you!

[Butanium]

Did the VSCode team tried to implement it ? What were the difficulties faced ?

[gnaggnoyil]

@Butanium It is technically impossible to figure out where the comments are without figuring out the language of the file first, and a file may be a legal content of multiple languages. E.g. a legal c/cpp source file may also be interpreted as a legal Makefile source file, and where the comments are depends on which language you are assuming. Even if a language can be specified first for a file, some languages may require a full parse according to the language grammar to determine where the comments are. For some languages, a successful full parse (that can determine the comments) might require to be run in project level, not on file level, and understanding which is the proper "project" is technically as impossible as determining the language of a single file.
Therefore, unless there involves discussion about how to redefine "comments" in this situation to make it technically possible and to make most user satisfied, this feature request can just then be considered the same as solving the halting problem. I personally think that a suitable reply in this issue might be either trying to discuss why this feature is actually doable, or some hints about the way of redefinition, or maybe even possibly both, and simply showing the strong desire of having this feature implemented without doing either of those above is not something suitable for a reply to development team of OSS VSCode.

[aaron-oxford]

@gnaggnoyil it's interesting that searching has a halting problem but not displaying files, where showing comments in a different colour works perfectly. very interesting that you'd choose this line of argument indeed...

[gnaggnoyil]

@aaron-oxford If you have a file that's both a valid C source file and a Makefile source file you'll find that showing comments are not actually working that "perfectly". But yes, "what is perfect" itself can be redefined in this context too, so that both user and dev team can be satisfied here.

[aaron-oxford]

@gnaggnoyil oh OK, i didn't realise that loading a certain file would cause the whole IDE to hang indefinitely :-)

[gjsjohnmurray]

@aaron-oxford I think @gnaggnoyil was referring to this.

https://en.wikipedia.org/wiki/Halting_problem

[aaron-oxford]

@gjsjohnmurray oh of course, how silly of me to forget that fundamental tenet of computer science that totally doesn't apply to colouring text but suddenly applies when Microsoft software users want a useful feature. It's like how in Microsoft teams when someone gives your comment a thumbs up it takes switching away from the conversation and coming back then clicking on the emoji and hovering over it for 15 seconds to clear it from your feed, but meetings that start in your groups don't show up at all and you have to manually hunt out the chat where it occurred.

It's because it's np hard, right? See https://en.m.wikipedia.org/wiki/NP-hardness

Maybe we need a karnaugh map see https://en.m.wikipedia.org/wiki/Karnaugh_map

I wonder if it's possible to construct some kind of approach on my https://en.m.wikipedia.org/wiki/Analytical_Engine

LMFAO

[WORMSS]

Can we move the bum tickling off this thread pls?

[anandncode]

@aaron-oxford

The syntax parsing and highlighting is dealing with 1 file at a time. But for search we are talking about hundreds and thousands of file (or may be more) at a same time. Search results should appear fast. From above comments it seems like, defining the comment syntax based on just extension alone, is not straight forward always and probably time taking. This can be still done, when we open 1 file but not with search.

My suggestion would be to enable the support for most popular languages like Js, Java, C, CPP, C# etc. Mixed cases like mentioned above, can be done later. The complex scenarios where it wont work has to be clearly documented.

Once rolled out, we can further improvise

[ambuddy]

Looks like a lot of people have been needing this feature for 7 years. Great this feature mentioned as a part of UI in Webstrom 4 years ago.

[papb]

@Butanium It is technically impossible to figure out where the comments are without figuring out the language of the file first, and a file may be a legal content of multiple languages. E.g. a legal c/cpp source file may also be interpreted as a legal Makefile source file, and where the comments are depends on which language you are assuming. Even if a language can be specified first for a file, some languages may require a full parse according to the language grammar to determine where the comments are. For some languages, a successful full parse (that can determine the comments) might require to be run in project level, not on file level, and understanding which is the proper "project" is technically as impossible as determining the language of a single file. Therefore, unless there involves discussion about how to redefine "comments" in this situation to make it technically possible and to make most user satisfied, this feature request can just then be considered the same as solving the halting problem. I personally think that a suitable reply in this issue might be either trying to discuss why this feature is actually doable, or some hints about the way of redefinition, or maybe even possibly both, and simply showing the strong desire of having this feature implemented without doing either of those above is not something suitable for a reply to development team of OSS VSCode.

This is a great point. Thanks @gnaggnoyil.

I propose the following to make this feature workable:

1. Instead of "Ignore comments", call it "Try to ignore comments"
2. Do it only for JavaScript and TypeScript for now.
3. Consider that a file is in JavaScript if and only if its name ends with one of .js, .mjs, .cjs, .jsx, .mjsx, .cjsx.
4. Consider that a file is in TypeScript if and only if its name ends with one of .ts, .mts, .cts, .tsx, .mtsx, .ctsx.
5. Show a warning for users that use this feature, clarifying the above points. A suggestion: show a tooltip on checkbox hover that says:

Currently, this setting only causes comments in JavaScript and TypeScript files to be ignored. Also, this makes the search slower.

After that is successful, improvements may be considered in other feature requests.

@gnaggnoyil and others, thoughts?

[aaron-oxford]

Let's define comments as "those things that would be considered comments if I were to open the file and look at it", and maybe let the user decide whether their valuable time is best spent waiting for the computer to parse thousands of files or manually trawling through thousands of search results.

We could even think outside the box and do something like run a normal text search to show the results quickly and then reclassify the matches in the files over time once we've presented them.

If we can keep a database of function signatures and other such information that works quickly enough to guess what I'm about to type based on things defined in files I don't even have open, I'm pretty sure we can also keep a simple map of code lines we know for sure are comments and use that in a relatively timely fashion while searching.

[papb]

"those things that would be considered comments if I were to open the file and look at it"

@aaron-oxford comment coloring depends on which language the file is assumed to be. What are you proposing for files whose language cannot be precisely inferred? For example, a file called foo whose content is 1 // 2? Maybe that nothing is considered a comment for them? If so, I think that's reasonable, it's similar to what I proposed above. What did you think of my proposal? Do you suggest more languages (and extensions) to start with? Which ones? Or maybe you propose another way of inferring languages, rather than going strictly by the file extension?

[papb]

@xiety May I ask what you don't like about my idea above?

[aaron-oxford]

@papb I think you're considering an edge case before we have anything concrete, but I agree with what you've said at the end.

Whatever way VSCode currently determines what language a file is, is the way we should use to determine what parser to use. If this doesn't work on some file and we can't determine what are and aren't comments and just search as normal, that's fine by me.

Oh and as far as languages to support to start with, my vote would be for C# files, but I'm not suggesting we limit that unless there's some language that isn't natively supported or is particularly egregious to parse.

[BenHanson]

See https://www.codeproject.com/Articles/1197135/gram-grep-grep-for-the-21st-Century

or

http://benhanson.net/gram_grep.html

or

https://github.com/BenHanson/gram_grep

I wrote this search tool in 2017 and I use it at work daily.

The config file for comments looks like this:

%%
%%
%%
[/][/].*|[/][*](?s:.)*?[*][/] 1
%%

and it will work for both C# and C++. You can easily create a different file if you are working with other languages.

You can then search with:

gram_grep -r -vf comments.g -E <search pattern> *.cs

This is a tiny fraction of the capabilities of gram_grep. See examples on my webpages that build up to search and replace using a grammar.

[bwardcse]

+bump, 2024

[DarrenCook]

From a comment above:

We could even think outside the box and do something like run a normal text search to show the results quickly and then reclassify the matches in the files over time once we've presented them.

This would be a fine way to do it, I think. It becomes a post-process step, so wouldn't interfere with the existing search, which ought to make it more attackable as a new feature? And then it is hopefully easy to leverage the existing syntax parsing functionality that each language already has.

From another comment:

What are you proposing for files whose language cannot be precisely inferred? ... Maybe that nothing is considered a comment for them?

I agree. I can already easily limit my search to *.js or *.cpp or even *.* if there are a lot of noisy hits from different types of file.