You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far we replicate the exclusion in VS Code, too. But since it doesn't do the indexing as Eclipse/IntelliJ it might be possible to open up visibility in the VS Code extension.
This would be in VS Code only. The language server would still ignore them because of the expensive Eclipse resource refresh underneath. However, that's probably ok since the use case should be mostly browsing files in there.
On thing to verify is the interaction of VS Code with the LS in this case. For example, VS Code should not try to send requests for .java files inside the bazel-bin to the LS. If it does the LS needs to ignore those.
This should be limited to bazel-bin only. It should be visible by default unless an exclusion (-bazel-bin) is defined in the directories list in the project view.
The text was updated successfully, but these errors were encountered:
Access to
bazel-*
symlinks is hidden in most IDEs because they cannot deal with them nicely.So far we replicate the exclusion in VS Code, too. But since it doesn't do the indexing as Eclipse/IntelliJ it might be possible to open up visibility in the VS Code extension.
This would be in VS Code only. The language server would still ignore them because of the expensive Eclipse resource refresh underneath. However, that's probably ok since the use case should be mostly browsing files in there.
On thing to verify is the interaction of VS Code with the LS in this case. For example, VS Code should not try to send requests for
.java
files inside thebazel-bin
to the LS. If it does the LS needs to ignore those.This should be limited to
bazel-bin
only. It should be visible by default unless an exclusion (-bazel-bin
) is defined in thedirectories
list in the project view.The text was updated successfully, but these errors were encountered: