[vlovich123]

I don’t know what linters you use, but the ones I like are the ones that show you problems in the workspace stably, not just in the files that happen to be open and altering as files open and close.

You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

[moring]

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.

> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

I claimed that it is possible, not that it is easy.

[vlovich123]

Im highlighting that defining that sandbox policy cohesively in a way that works for all the different extensions types you’d want to support and doesn’t overwhelm the user with permission fatigue is difficult as to be impossible.

Browsers have a different problem - they protect different websites against each other. The IDE should probably protect you against extensions being able to access arbitrary files on disk, but even that’s difficult (eg a bundled linter often wants to read user defaults in a central location. But protecting even further than that is even harder, especially as here where the access was to the actual repo not anything else.