Anton said:
Hi Emile, we're working on creating the best editing experience for roc with our own editor. It is still missing many core features, so everyone uses their preferred editor with CoffeeScript or Elm syntax highlighting.
Ok I see. But I don't really get the benefits from a dedicated editor. For me having a language server will be far more efficient as it will allows more traction by allowing people to use their favorite editor...
Richard has given some great talks on that very question, have you seen those videos?
I recommend 29:50-44:40 in this one: https://youtu.be/cpQwtwVKAfU
He also explains some higher-level goals for the editor at 1:40:00 is this video: https://youtu.be/ZnYa99QoznE
Although I'm writing Roc in VS Code and I would benefit greatly from a language server, I'm glad that the Roc project is currently prioritizing long-term DX innovation over short-term community growth. The editor's goals are very lofty, and it may require a monopoly over first-party support in order to achieve those goals.
(However, I'm not an authority on anything, I'm just a Roc Editor spectator!)
Hello @Emile Rolley
As @JanCVanB said goals are extremely lofty, and I am currently working on documenting them in the prototype and Wiki form.
The goal is that working with Roc code in the editor is fun and brings you that nerdy happiness of being playful with the ideas.
On the other hand I totally understand practical drive lets get LSP up and running! I am not against it, I even went into deep end with LSP and VSCode documentations.
But time is limited and I would rather focus on the things that might bring much greater breakthrough. As a community early on we nodded all together (with Richard giving a wink) that it would be much more fruitful to work on bright future than plugging YAPL in VSCode/Neovim/Emacs.
I am happy to share ideas with you, and receive any feedback that you might have.
If you find that LSP project is intriguing, feel free to give it a stab, nobody has anything against it.
But you might as well come in and help developing Most Rocking Awesome Editor Ever® !! :P
JanCVanB said:
Richard has given some great talks on that very question, have you seen those videos?
I recommend 29:50-44:40 in this one: https://youtu.be/cpQwtwVKAfU
Thanks for your answer.
I just watched the talk, but I still confused about the benefits, indeed, all the introduced features seems implementable inside a VSCode extension. I'm not an expert but I think structural editing can be done with tools like tree-sitter for example.
Overall, I understand the desire to try new things and I hope you will achieve what you wanted :bird:
There are many features we could implement in a VSCode extension but I don't think it would be possible to load roc library plugins (written in roc) through that extension. We consider that to be a core feature of the editor.
We'd also lose a lot of freedom and control. If VSCode developers decide to not allow something or no longer support a feature we'd be powerless to change it.
I actually would like to further investigate the trade-offs of "true" structural editing vs a tree-sitter approach, thanks for bringing that up!
For what it's worth, the Elm language server VS Code extension can load & run elm-review rules and elm-test tests (both of which are written in Elm) and show the results in the editor. So maybe it would be possible to do the same thing with Roc plugins, at least to some extent.
I think the idea of library authors writing custom plugins for their libraries is really neat, and I think something like that is kinda already possible in the elm community with elm-review - although I haven't actually seen a library author include elm-review rules as part of their package yet.
And for sure you can not make the plugin float or be pinned in VSCode.
I really appreciate the pressure and criticism that this might not work.
Makes me even more excited to try it out. :)
Sorry, I didn't mean it to be pressure or criticism at all! Just like: here's something cool that can already be done, it's exciting to think about how much further these ideas can go if we have even more freedom to implement them!
I moved this discussion from introductions to its own topic.
@Ed Kelly we welcome criticism :)
From what I can tell, the elm language server runs elm-review and elm-test basically through the command line. We had tighter integration in mind with plugins.
Anton said:
Ed Kelly we welcome criticism :)
In deed! :)
But please, how can you tell me that we can't to better than this!
Screenshot-2022-01-21-at-15.29.43.png
All the tools are awesome, both Elm, and VSCode, and elm-vscode-thing
but still, look
We can do much much better than this!
Especially because we have the luxury of the Roc's concepts!
Is there any highlighting for roc yet?
coffeescript works ok
there's some explaining about why there isn't any yet that every newcomer gets told eventually. but TLDR; because roc is working on it's own editor we try not to provide "official" support for other editors in an attempt to grow the community around a common editing experience with a rich plugin ecosystem
Here's a video that answers this category of questions, from... today! :laughing:
See 3:32 in https://www.youtube.com/watch?v=ITrDd6-PbvY
Credit @Lucas Rosa for sending me this.
I see that this makes a lot of sense but (and I’m sure other people already said this so sorry for my newbie-ignorance) there will always be people that don’t like to switch context when e.g. working on a platform.
There are people that go to great lengths to stay within Kakoune/emacs/vim (maybe VSCode) and that would rather use lsp (and maybe a preview plugin) than having to switch context when editing rust (or zig) code and roc.
And besides text editors there’s also tools like bat
/pygments/pandoc and the like where code highlighting already in early stages would rather help growing the community (I guess?).
Is the idea that the editor will eventually get plugins for editing Rust/Zig/C++/Swift/etc? (So, should the editor also support LSP?)
If you mean the roc editor, I think it's meant only for Roc, and main focus will be supporting Roc editing as much as possible
Yeah, most roc author's shouldn't need to write platforms. At least that is the hope. They will just download an existing platform for what they need. So probably won't really have support for other languages.
If you want to use e.g. a java lsp with kakoune, you would use the lsp that eclipse uses internally.
So _maybe_ in the end (like some point in the future when the editor works and is established) there will be some components within the roc editor that can be used for a roc lsp?
Long term after the editor has had a chance, it is possible that we would enable using components of it as part of a language server (or someone will just fork it and do so). We just want to give it a leg up and a solid head start before any LSP is made, if that is possible.
Does anyone have some basic Roc extension for VSCode. Just for some basic syntax highlighting.
(Or some other "mainstream" editor that's not Vim or Emacs ;) )
I do like the idea of a specific editor for the language. But until then it is nice for us noobs to have some basic stuff going. :)
(I did try using Elm syntax highlighter but it got confused almost directly)
Not yet, coffeescript syntax highlighting should work decently, see also this question in faq
Thanks again Anton :+1:
Last updated: Jul 05 2025 at 12:14 UTC