Autocomplete is for Ruby too!
Do you have editor-envy when you witness other programmers using fancy IDE features like go-to-definition or auto-complete? Perhaps you've only witnessed this with other languages - maybe those with static typing - but that's not how it has to be.
Powerful - albeit sometimes obscure - open source tools with all these features are available for Ruby. Come hear more! I'll explain the building blocks of code intellisense features; something called Language Server Protocol; a Ruby language server called Solargraph; the solargraph-rails gem; and how you can get involved to make them even better.
This content will only be visible to the review committee. Include any pertinent details such as outlines, outcomes or intended audience.
This is not just a "here's the YAML you write to add intellisense to your workflow" talk. This is about explaining how intellisense tooling works and how it can be accessed, in order to empower a community that believes that good tooling is for other languages.
Outcomes:
- Expand horizons about in-editor tooling for Ruby (good tooling is not just for typescript)
- Dispel myths about intellisense and static typing: types are helpful but not the only avenue for analysis; we can consider inference, structured documentation, and convention too.
- Identify the building blocks of intellisense tooling: parsing, in-memory abstractions to represent code, protocol to answer questions from editors, editor plugins to provide developer UX
- Explain how Language Server Protocol defines an interface that allows editor-agnostic language servers to be built
- Inform the audience of the existence of Solargraph and how their editor already has a plugin for it
- Explain how Solargraph's plugin ecosystem allows easy improvement
- Introduce solargraph-rails, which aids Solargraph in understanding Rails' metaprogrammed features
Audience:
I've met many programmers recently who believe that Ruby tooling is bad and other language tooling is good. Some even think good tooling is solely a feature of one other language they've worked with, often typescript. If they knew that better tooling existed, they'd want to use it. If they understood what the building blocks are, they'd understand how to configure the less user-friendly parts; possibly even be inspired to contribute to it.
In his RubyConf 2021 keynote, Matz explained to the community that previously, Ruby's UX improvements came from changes to the language syntax, but that going forward the UX will come from better tooling. LSP gives the Ruby community a powerful platform for users and creators of such tooling. There are really big Ruby projects already written in LSP, and we get to build on top of them. Crucially, when we improve an LSP server, our efforts are not solely for a single editor, we improve the quality of life of the entire ruby community, no matter which editor they use.
I'm the creator and one of the maintainers of solargraph-rails, a plugin for solargraph that inspects metadata and documentation in your Rails code. It improves Solargraph's awareness of things like ActiveRecord attributes and associations. Once Solargraph is able to supply this information to your editor, your editor is able to offer features like go-to-definition to you.
Yes
I'm Fritz Meissner, a developer at thoughtbot EMEA. I lived in Cape Town in South Africa all my life until 2021 when I thought I'd try a travel adventure in the middle of a pandemic, and moved my life to London.
I'm the author of solargraph-rails, a plugin for solargraph that gives solargraph some extra help to understand Rails' metaprogramming magic.
I only had time to give this a brief read, but it looks good to me.
This phrasing took me a couple of tries to grasp, though. And I'm still not certain I understood it entirely.
But my tldr review is that this sounds really interesting and I hope it is accepted!