Recent searches
Search options
Administered by:
waiting for summer 
One of the interesting/unexpected barriers of entry with modal/TUI editors is language support. It makes sense, when you think about it though.
I don't mean plugins, which aren't the worst option, but actually-good language support like a language server and linting etc. Both of those things may be easy to plug in to your editor, but the domain knowledge required to get them setup can be a huge headache if you've never touched the domain.
E.g. I spent a _lot_ of time yesterday trying to debug Solargraph not working with my Ruby app at work. And even more time somehow getting Rubocop to lint correctly. I'm new to Ruby, and I was trying to get this setup to give it a good shot, but I didn't know what bundler was or if/how/why Solargraph and Rubocop needed to run using bundler.
I've since updated Kakoune's wiki with an example for running the LS in bundler, but man was it a PITA to figure all that out.
On the other hand, I've learned a lot about the Ruby runtime and environment from setting that up, and I can see the intrinsic merit to learning that before diving into the code base. But if you have a deadline, if you need to ramp up quick, or if you are just touching something once and moving along it's hard it can be hard to justify putting in that time; why spend 6 hours figuring all this out if I need to have this thing done in 8?
It's a hard problem, but it's an important problem...
For the vim/kakoune Rails programmers out there: what does your language server setup look like?
Coming from Rust, Go, Python, and Typescript I am struggling with the limitations on intellisense and heavy reliance on conventions. I'm curious what a pro's™ Rails dev setup looks like for terminal editors.