3 ms·
I started on my own "multi-language/multi-editor" (potentially) out-of-process "language server" (sans an established protocol) in Go (json over pipes because w
by dualogy 10y ago
I started on my own "multi-language/multi-editor" (potentially) out-of-process "language server" (sans an established protocol) in Go (json over pipes because who needs sockets) as the MS-initiated LSP was and it seems remains very much in flight and in flux, still evolving. Once it matures and a fair number of other editors adopt it (to lend it long-term viability), I'd probably switch said backend process from custom-hodge-podge-protocol to that standard.
Of course the motivation here was to begin building out something I can easily extend to other editors and languages over the years to come as I noticed after some 15+ years that one switches out both editors and languages not-frequently-but-recurringly over a longer timeframe. At some point I assessed Sublime as abandoned and VScode as pretty damn hot, but the real lesson here of course is that some independence from one player's to-be-neglected-in-the-future tooling and/or protocols is .. pleasant. In the same vain, when I do switch I won't have to switch from a dozen 3rd-party nodejs-"powered" extensions to a dozen 3rd-party python-"powered" extensions but can just script up one lean frontend shim from the editor's extensibility API to the actual meat furnished by said Go-powered backend.
Bit of a funky concept. It really started out as "this is gonna be a weekend effort, heck I just run existing 3rd-party tooling command-line processes and pipe their results back over json sanitized and somewhat processed". Enter countless intricacies and we're talking a real code-base even for something initially-apparently utterly trivial and one-off! All the better to attack it once, in full.