Make debugger respect "files.exclude" or introduce a hiding mechanic

[Spown]

Currently the debugger doesn't seem to care for settings.json:files.exclude. For example if I exclude **\node_modules (I assume that 99% of all errors are caused by me and things like Q, mongoose, lodash are relyible enough to not spend half of my time on clickfesting step out of these files) - the folder gets removed from the navigator, but when I traverse through breakpoints in the debugger - the node_modules files are still shown (not in the navigation column, but in the editor). I understand that files.exclude belongs to project settings, while everything debugger-related is controlled via lounch.json. These are 2 completely different entities or workflow layers that in theory shouldn't ever collide. So I guess there should be a separate config option in the lounch.json for debugger to silently jump over the excluded files. Like the --hidden flag in https://www.npmjs.com/package/node-inspector. Optionally, if so - there should be a level of control over the hiding for unhandled Exceptions:

"files.exclude": {
        "**/my_modules": false //always shown
        ,"**/libs": true //always hidden
        ,"**/node_modules": "normal" // jumps over the file if there is no breakpoint or unhandled 
        ,"**/trusted_node_modules": ["normal", "exception"] // jumps over the file if there is no breakpoint, or any other stopper except for the defined ones
    }

Also I think there should be a way to make the debugger ignore core modules either through a dedicated option or through a files.exclude key with a path-forbidden character, like "?core_module": true or something.

Thank you.

[Spown]

yaah, as I mentioned in #3260 there is an additional inconvenience: the recently opened list gets cluttered with a ton of unwanted files...

[weinand]

The individual feature requests for node-debug and node-debug2 are:
microsoft/vscode-node-debug#16 and microsoft/vscode-chrome-debug-core#7

[weinand]

As for the syntax of the new attribute I suggest to use the same glob pattern approach as for outFiles. The name of the attribute could be blackboxFiles or blackboxCode. I don't like libraryCode because it tags code as 'library code' but that doesn't reveal what it really means.

@Spown @roblourens do you have better ideas for a good name?

[Spown]

Glob pattern is obvious.

Concerning the name however if I didn't know what this option would do I would think of something completely different if it would be called blackbox*. Frankly I probably wouldn't be able to make sense out of it because blackbox in my book is tightly linked with some input and output values. So I would think it somehow connected to variable inspection. I mean it's not like it is illogical, just not straightforward intuitive. Maybe something like bypass* or skip* or something like that. Also I don't like library*as well, but since it is already in use maybe introduce them as alias?..