Improved support for globs in multiroot workspace #1083
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1063 #959
Replaces #1065
Currently globs are applied equally to all workspace folders
This approach is backwards compatible with single-root workspaces (and existing configuration)
It adds the possibility of limiting the glob to one of the directories by starting the glob pattern with the directory name.
Seems to be a bit of a complicated topic even within VS Code itself, see microsoft/vscode#82145 (comment) (amongst others)
How it works
In case there is more than one workspace folder, the glob can include the folder name to limit its application to that folder. If the glob is generic it still applies to all folders. For example, given:
and
Given the
random/**
globnotes
folder is open it will ignore everything inside therandom
directory (current behavior)notes/random
andwork/random
(current behavior)If I only want to only ignore the
random
directory innotes
, this was not possible.With this PR, I can use the glob
notes/random/**
to target only one of the root directories.Can it be confusing? Maybe but I am optimistic it won't:
when the workspace has a single folder, you don't see the folder in the explorer, so intuitively you wouldn't use it in your glob (which is also the behavior today, and the reason why on simple projects we haven't had issues).
When the workspace has more than a folder, then they show up in the explorer, so it does "feel" more right to include it in the glob
So the root folder "becomes" part of the explorer, and in the same way I can see how it could "become" part of the glob.
If a glob doesn't match a specific workspace folder it will apply equally to all of them (as it is today).