-
1) Pick an editor and get to know its API. VS Code is good as it has a very restricted and simple API that is easy to write extensions for. It has samples for various its various providers. I haven't bothered looking at other editors, but I am guessing they will have similar offerings.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
2) Assuming your editor plugins are in a different language than the one you are writing your own in, you are going to need a way to interface the two across processes. I ended up picking ZeroMQ for linking VS Code editor plugin which is written in Typescript and Spiral's compilation server which is written in F#.
-
3) This third part is the hardest, and that is to get proficient at concurrency itself. For this I had to study various libraries like Rx, but what I settled on after a lot of experimentation was to first compile the various passes to streams of lazy promises. For languages in particular, they have a top down structure and what is needed is to employ a lot of diffing in order to reuse old results. The difficult part is to organize all of this. I can't praise a library like Hopac enough, but even with it, it still took me months to get a grasp on the way the editor support segments should be designed. At the time of writing, I am a day away of finalizing what will be the true design of the language server. It is not that the end result is complex, this latest redesign of the last 1.5 weeks is in fact significantly simpler than what I had before, but concurrency requires different design principles than sequential programming and getting used to the new domain takes an active effort.
