That does sound a lot better. On Arch Linux, my girlfriend was actually stymied installing the TADS vscode extension because of all the dependencies on Node and TypeScript. That’s probably not a universal experience, but installing it that way feels gross anyway. To reach parity with most other LSPs, I think just putting three binaries up on the release page (windows, macos, linux) for people to manually download themselves should be enough, then they can just tell my Emacs plugin where to look.
Hm, that’s odd. As I made the effort to make it a published extension she shouldn’t need to make a manual build with npm. It’s searchable in the extension tab within vscode. It should just be a one click installation from there.
She uses VSCodium, I think that was the issue.
Out of curiosity, because I don’t know too much about how LSPs work, there’s a standard lsp-mode that Emacs uses to connect to all the LSP backends for various languages, which is then activated when a given major mode launches. Does your TADS LSP adhere to whatever standard JSON format other LSPs use? Because if so this might be a plug n’ play solution!
1 Like
It adheres, since it implements the interfaces for the 7.0.0 version of the LSP protocol. (The client and server communicates with classes serialized
to json. )
I’ve added a few special messages for the map feature besides those but they are voluntary to listen to. So in theory, yes for the client it’s just to start it up with the server. Not sure if lsp-mode takes care of the installation of the server though. But in case it does. A PR to their repo might be the way to go.
1 Like
This is really cool! Although testing out the Inform7 mode, I’ve noticed the syntax highlighter gets confused if you put a word or phrase in parentheses in a comment, like [this is a comment that I might (ideally) like to use].
1 Like