When working with code, I tend to be a person who jumps around between various editors rather than being completely fixated on a single one, for better or for worse. Generally speaking, the following editors are in my normal rotation:
Out of these, I don’t think I’d say that I have a favorite; each has their own pros and cons. For example, VS Code is by far the easiest to use and, being the most popular, is all but guaranteed to have support for the latest and greatest extensions. On the flip side, it’s super bloated, resource intensive, and tends to be slow since it’s Electron-based. Neovim offers the most customization and best editing experience (assuming you’ve put in the time to learn all of the Vim motions, something that’s well worth doing), but is also the most difficult to configure and troubleshoot when something goes wrong. Sublime is insanely fast, but it costs money and tends to fall behind other editors on extension support.
I don’t hear too much chatter about Sublime in programming circles these days, to be honest, but I recently stumbled across a great blog post titled Why I still like Sublime Text in 2025. It was a terrific read that highlighted a handful of features that I wasn’t even aware of in Sublime. A lot of features, while interesting, aren’t really useful to me in my day to day work, however. Things like multiple cursors or snippets, while undoubtedly a big draw for some, just don’t seem useful to me. That being said, one thing in particular caught my eye with respect to the LSP:
I know VS Code is the LSP king, which the tech originating with that editor, but I haven’t seen the ability to just add an LSP installed as a binary in on your
usr/local/bin.There are a few “cutting-edge” LSPs that are installed via Cargo that are usually only targeting Neovim, but can easily be configured in Sublime with a simple JSON object.
https://ohdoylerules.com/workflows/why-i-still-like-sublime-text-in-2025/#lsp
This was particularly interesting to me because one of the languages I generally struggle with editor support for is Groovy. I write a fair bit of Groovy at my current job, and for most bigger projects I just use IntelliJ IDEA because, frankly, it’s the only passable experience for authoring Groovy. Sometimes, however, I just have a smaller script that I want to do a quick edit on but would still like some LSP support. While not exactly fully fleshed out, there’s a basic demo Groovy language server on GitHub that I’ve eyed before without really looking too much into using. They even include a sample using it in Sublime in the repo, but I never paid it much mind because I assumed it would be a hassle. That couldn’t be further from the truth.
Obviously the first step to using the LSP was to compile it, which can be done with a simple ./gradlew build. After that I could easily configure Sublime to use it by opening up: Settings > Package Settings > LSP > Settings. As is often the case with Sublime (which I love), this opens a JSON file. In it went the following:
{
"clients": {
"groovy-language-server": {
"enabled": true,
"command": [
"java",
"-jar",
"/path/to/lsp/jar/groovy-language-server-all.jar"
],
"languageId": "groovy",
"syntaxes": ["Packages/Groovy/Groovy.sublime-syntax"],
"scopes": ["source.groovy"]
}
}
}That’s all there was to it. The next time I opened up a directory with a .groovy file, I confirmed I could do basic things like hover over a method to get its definition, pop up to the definition, find references, etc. There were some issues, but they were all related to a niche and not maintained language server rather than anything to do with Sublime. For example, the server has a habit of crashing, though it’s easy enough to restart from Sublime’s command palette whenever I notice this has happened.