nwscript_lsp is built around a newish (the start 3ish years ago now) hand-rolled recursive decent parser, typechecker / ast resolver and read-only python bindings to the AST. Its just an LSP Server so it’s editor agnostic, neovim is just one of many editors one could use with it. And it would work fine with any game that uses nwscript. NWN(:EE) is just the one it can read game files directly. The parser is significantly more resilient to errors and more comprehensible than the official compiler.
This is still in an unrealeased-ish, but usable, state since
I’m in no rush
I don’t have particularly strong opinions on nwscript development,
I don’t want to introduce anything new, e.g. if nasher.cfg can inform include paths (I don’t know), there’s no reason to do anything else
I wanted to see if there were any other fellow travelers out there, especially whose goals are different than mine, who would be interested in such a project.
It’s not intended to be competition with any other project, and, who knows, it could serve a more gentle introduction to compiler front-ends than the official compiler. A cup of coffee and a couple kloc and you know all there is to know. This is part of broader personal hobby project exploring a tools-based approach to what technologies and things one might use / learn if one were to try to bootstrap a game like nwn / nwn2 in the $CURRENT_YEAR (for scripting: wasm with gas metering, maybe?).
For those I’ve offended on account of my low opinion of ~redacted~, please take this as a public apology: I shouldn’t have tried to contribute to stuff I never liked, or been overly combative with other community members because of it.
No, not if you’re referring to nwscript-ee-language-server. I’ll never intentionally speak ill of good faith contributions to this community, that project makes technical decisions that I would not make and isn’t in line with my goals. It even discusses in its README the tradeoffs between itself and real parser and AST:
“The language server symbols or tokens are not generated using an AST like language servers usually do. The NWScript Language Server exploits its TextMate grammar, which is derived from C’s, to transform a file of code into tokens. While it works well for most cases since it is a simple scripting language built on C - even for a language like NWScript, we need to cheat and use lookahead and lookbehind strategies to ensure we are in the right context -, it will also fail for complex or uncommon code structures and styles. A TextMate grammar will never cover the most extreme cases of a language grammar. An AST represents the hierarchical structure of a file of code in a much more complete and precise way.”
I’m not really interested in editor plugins, neovim was just an example since its nice. There are other technical issues that I’d only go into with consent.
I actually currently use nwscript-ee-language-server with neovim, and it looks like the method is essentially the same (after you strip out the keybinds, etc.).
Thanks, leo. Will give this a shot. Btw, you might try using tinygiant’s tree-sitter-nwscript for syntax highlighting in neovim.
That’s pretty slick that you can load vscode plugins in neovim. I would have thought from a cursory glance it was pretty much tied to vscode. I’ll definitely check out the tree-sitter.
As I see it, that project is facing a not so great issue: the end of nwnsc (I guess?) and how terrible the official compiler diagnostics are. Maybe clippy, daz, etc can turn that around like they did nwnx:ee.
If there are people interested in collaborating, turning this into a nwscript linter type program to bridge the gap would be pretty easy.
Dunno if anyone gave this a real whirl or not but I’ve updated the parser for latest stuff: the macros (FUNCTION, DATE,etc), the hash string literals, the binary and octal literals. For open proposals, like a decl in for loop init was already implemented as nwnsc. Not sure about the switch and while parts, will wait for dev team green lighting that.
There should also now be a native arm64 Python wheel for Apple Silicon users for the underlying library.
A moderator can feel free to lock this, all further updates will occur on my arclight project thread so as to minimize my forum footprint.