It's not at all pretty (read: I've done regrettable things), but I've ported the VS Code extension from TypeScript to Nim.
Noteable changes:
Haven't picked what I want to do yet, but I've been thinking about:
Collaborators welcome, doesn't have to be on the above stuff.
I'll pre-apologize, but I went for more of a mechanical transform at first, still much of that lying around.
Also, I'm learning Nim along the way so you'll likely be asking yourself, "why didn't they do X?" The answer is I don't know better/didn't discover it yet/learned it really late. For example learning I could straight up use async/await in the current electron/node version.
as someone who contributed a little bit to the Nim vscode extension in the past I'm glad someone's bringing a fresh breeze into this area, thank you for that!
Something I want to mention is that the original vscode extension (and by extent also your translation) have a lot a lot of half functional attempts at things which I want to discuss. One example would be my trying (mea culpta for that) to determine which argument of a function signature is currently filled in. This improvisation of a parser fails to work in a number of cases and looking back at it would probably be better to just remove it and show the signature without highlighting one parameter. Other examples of this are the import suggestions which suffer from the same problem.
One more controversial example would be the behaviour to spawn a nimsuggest instance for every file if no project file is/files are specified in the settings which originated when nimsuggest couldn't handle files which weren't part of the import hierachy of one of the project files. While the ideally we would be to always have only one nimsuggest instance, problems with large projects can occur.
Something I want to mention is that the original vscode extension (and by extent also your translation) have a some half functional attempts at things which I want to discuss.
Yes please, there is a bunch of history I've been trying to suss out. On top of which just developing good taste with Nim I've found rather challenging. I think the biggest thing I've been trying to reason about is what are the fundamental concepts and a rigorous taxonomy of them within the code so everything is more obvious.
One example would be my try (mea culpta for that) to determine which argument of a function signature is currently filled in. This improvisation of a parser fails to work in a number of cases and looking back at it would probably be better to just remove it and show the signature without highlighting one parameter.
No need to apologies, it's not perfect but it works enough of the time and provides some utility. In fact, I distinctly remember a few times when I broke the code and immediately began to miss it. Pretty sure I introduced a new set of quirks, turns out slicing and substring semantics can be rather subtly different.
Other examples of this are the import suggestions which suffer from the same problem. > One more controversial example would be the behaviour to spawn a nimsuggest instance for every file if no project file is/files are specified in the settings which originated when nimsuggest couldn't handle files which weren't part of the import hierachy of one of the project files. While the ideally we would be to always have only one nimsuggest instance, problems with large projects can occur.
In both of these cases I think the first thing is working out what exactly is a project. That is to say having a starting taxonomy of "reasonable" file system layouts of Nim projects where user intention can be sufficiently inferred. The rest can be covered with some overrides/declarations.
If such a taxonomy existed the modeling it and determining a minimal set of nimsuggest processes for that to be supported would be all that much easier. As for imports, if we can determine the projects then we can scope the imports to them and this has far reaching effects, like controlling backend and other key defines.
In the long run, project structure in general is an area where I'd much prefer opinions from Nim/upstream -- not simply for the extension but tooling in general. Ideally Nimble based and over time nimble itself can become more declarative than imperative. I'm getting ahead of myself here.
Aside, I spent the weekend toiling away trying to replace nedb, I got something sketchy working based on a port of [flatdb]<https://github.com/enthus1ast/flatdb>_ but I need to debug a bunch of asynchronous file writing issues. Now I'm heavily reworking the IO and simultaneously moving away from Nim's Tables, etc... it's just a huge impedance mismatch between them and JS.
While reflecting on all this and looking at the code in general, things are messy (module level state, poor integration of data sources, caches, and lifetime management) and to top it all off I've made them worse by bashing the keyboard until it works. I think a fair amount of domain modeling needs to be done and a lot more heavy lifting done via precise and thoughtful types that reflect the concepts in a rather fundamental fashion. Everything else is much more likely to usefully organize around that than bashing random cint, cstring, and seq into weird shapes and hoping to get an IDE out of it.
I took a quick scan and this looks like exactly what I need, thanks so much! Also gives me another place to go spelunking because there is a bunch of overlap in this area.
I also did a quick search in the git repo and I see hits in nimsuggest and nimfind, which got me thinking does a findAllProjectFilesInDir, exposed via command line, seem like a useful addition to one of those or other tools? For now I'll simply port the logic but trying to get a feel for things.
Amazing! Thank you for making it easier for the Nim community to contribute to one of the most important tools we have.
I have a request for you, when designing new features and deciding whether to keep existing ones in the extension, steer towards not getting in the users way by default. Subtly broken automatic indentation or auto complete that makes my MacBook Pros fans take off really make something irritating to use. I've personally resorted to disabling these but figuring out how to do that was in itself painful, especially when just trying to get work done :)
Anyway, maybe this will be the catalyst to get me to contribute to this.