burner1024
commented
2 months ago That's cool. I've been meaning to get to ANTLR4 next, in particular as the road to autoformatting.
Language-specific features I prefer to put into corresponding weidu.ts or fallout.ts files. Or, failing that, route through Galactus
https://github.com/BGforgeNet/VScode-BGforge-MLS/blob/96f48ca36786d74adf080e13118c2c3de1d6dfbb/server/src/galactus.ts#L231-L233
But there's been no need for language-specific lookup. I guess you can pass langId to symbolAtPosition and handle the switch there, in common.ts
Doesn't current symbolAtPosition return correct symbol, though?
They can be generated by build script instead, but that would require java dependency during build which might be undesirable.
Yes, will need the generation script. Not necessarily at build time, but need to have a way to regenerate this automatically.
See https://github.com/BGforgeNet/VScode-BGforge-MLS/blob/master/scripts/ie-update.sh for an example. I just checkout upstream repos into ./external and pull data. Kind of horrible, but better than nothing, upstreams don't change often.
Also seems ESlint is plenty angry.
This PR adds limited go-to-defintion feature for weidu .d files.
Definitions are collected only from open files. Go-to-definition works only for GOTO and EXTERN weidu commands.
Notes regarding implementation:
Holding clrl causes file to be re-parsed on every cursor move. I did not notice any visible impact on performance even for large files, but you mileage may vary.
I got a bit confused about how to implement a language-specific symbol lookup, and went the most direct way. Suggestions on how to properly improve that are welcome.
Files in
src/dparser/*were generated from this grammar: https://gitlab.com/lapdu/lapdu-parser/-/tree/master/src/main/antlr4/imports They can be generated by build script instead, but that would require java dependency during build which might be undesirable.