Yes, as in "check the number of parsed fields for each line" and don't forget about empty fields. Throw an error and stop the program if the number of columns isn't consistent. Which doesn't mean that you can't parse the whole file and output all errors at once (which is the preferred way, we don't live in the 90s any more ;), just don't process the wrong result. And with usable error messages, not just "invalid line N".
To be honest, Theia (the last beta I tried some months ago) is everything people always complain about Electron apps: slow as molasses - way worse than e.g. Atom (or Pulse) (which VS Code actually isn't).
Everybody can do that themselves, if the original maintainers don't want to (which is a security problem ;):
If you are not the author, we suggest you first reach out to the author with an issue in their GitHub repo to request that they publish their extension to open-vsx.org. We've drafted a template with suggested content for the issue.
Yes, their C++ LSP isn't really good and I've heard C# isn't good either - but that's because they want to sell Visual Studio too. But especially "Remote SSH" and "Dev Containers" are so called game changers. And their Typescript and Python extensions are actually good.
C# extension works well and uses Roslyn Language Server that is part[0] of the Roslyn (C# compiler) itself - this is what the base C# extension[1] uses. Both of these are licensed under MIT.
The closed-source part is 'vsdbg' which is Visual Studio's debugger shipped as a component that the extension uses. It, however, can be replaced with Samsung's 'NetCoreDbg' by using the extension fork[2].
[2]: https://github.com/muhammadsammy/free-vscode-csharp (please consider giving it a star, it's the only actively maintained alternative and other tools end up relying on it downstream to support debugging - VSCodium as well as Emacs and Neovim with VSC extension bridges)
Lately they've begun embedding the same C# analysis stuff they have in VS into VSCode if you pay for the license. I haven't used it in anger (long since left for Rider), but it has come in handy when troubleshooting people's VS issues at work from my Mac. The test explorer now blows up in exactly the same way in VS and VSCode :)
> Zed exists, it's new but it's already a very good IDE.
An IDE needs at least a working Debugger (or, to be more precise, a graphical interface to debugger(s)).
And Zed has exactly the same problems VS Code has, minus actually contributing LSP and DAP (Debug Adapter Protocol) to "the editor community". So, Zed is actually worse in that regard.
> An IDE needs at least a working Debugger (or, to be more precise, a graphical interface to debugger(s)).
For me that should read at _last_ (or not at all).
While almost any IDE I ever used had a debugger (starting woth Borland Turbo C++) the number of times I used one I can count on both hands. And even then, a CLI to the debugger is just fine.
Like with any feature an IDE may offer, there are people for which that very one is essential.
Fair enough; but don't assume your non-negotiable X is the same for every other user of an IDE. It is not.
I'm sorry, but what _is_ the difference between an editor and an IDE for _you_?
Btw. I'm not saying that having an integrated debugger is a sufficient condition for an editor to be an IDE (VS Code isn't, Sublime Text isn't, other editors with DAP support aren't).
> but don't assume your non-negotiable X is the same for every other user of an IDE. It is not.
But _you_ not needing a debugger in an IDE is a reason something is an IDE without one, I see. Btw. I'm (normally) not using IDEs.
Wikipedia[1] says an "IDE normally consists of at least a source-code editor, build automation tools, and a debugger". Not that is says "normally", not "definitely".
And in the next paragraph the "definition" encompassing a continuum of features and not a definite set is further clarified.
My point was that "X is missing" => "this is not an IDE" is not true for this reason.
> I'm sorry, but what _is_ the difference between an editor and an IDE for _you_?
For me an IDE "knows" about other files I have open and their relationship with the one I'm editing (usually a "project") and it _i_ntegrates external tools/programs.
An editor does not. It just lets me edit a file. Maybe it has syntax highlighting or folding but everything it offers is based on that file. A good example is SciTE which was my go-to for years.
In an editor you can't right click on some type in the current file and choose "Go to definition" if that definition is another file.
Of course there is a continuum. For example, running an external command is something many editors offer. And if your file is of a certain type they may even guess what the (build) command may be.
When you have non-local (=outside the file you're editing) functionality and some integration with external tools I'd wager you're using an IDE of some sort.
Then you can argue if that IDE ticks enough of those boxes defining your needs, fair enough. But you can't say something isn't an IDE because it is not an IDE for you. ;)
P.S. non-negotiables for me are mostly around that VCS integration. But I acknowledge that other people may not have this need (are fine using the command line for this only). But that only means I would not use an IDE that lacks those; I would not therefore say it isn't an IDE.
> For me an IDE "knows" about other files I have open and their relationship with the one I'm editing (usually a "project") and it _i_ntegrates external tools/programs.
With that definition any usable editor and vim-likes ;) is an IDE. I can live with that (that Zed is an editor comparable to them) too.
It's called OpenVMS since quite some decades now.