I assumed that Neovim’s LSP support is more advanced, as I only hear about it and not regular Vim.

That said, I never managed to migrate to Neovim, it felt like an entirely new ecosystem.

I think the main blocker was that Devise maintainers didn’t accept any of the prep PRs, such as making passwords optional.

That’s probably because Devise has been in strict maintenance mode for the past 6+ years, due to possible fear of breaking things with significant changed (that’s my POV).

Hmm, works for me, as long as I hold "cmd".

Very nice, well deserved!

Yeah, the Claude Code ACP adapter provides only a subset of the terminal features. So, if you’re a power user, you might still prefer the full terminal version.

github.com/zed-industri...

I've been using Claude Code inside Zed over its built-in agent, and it's been working pretty well for me.

I've heard that Zed's edit predictions aren't nearly as good as Cursor's autocomplete. You can use Copilot instead of Zeta, but that only activates when you're at the end of the line.

I recommend reading through the Ruby docs and enabling the things you want (some things have changed recently) – zed.dev/docs/languag...

There is a Stimulus extension – github.com/vitallium/ze...

Recognize Rails fixtures as YAML+ERB:

{ "file_types": { "YAML+ERB" : ["**/spec/fixtures/**/*.yml"]} }

Also, the page title (<title>) still mentions "Tailwind UI", which seems like it should be updated after the rename 😉

Well, in my experience AI can’t write decent tests 😛

It doesn’t seem to think of reusing factories/fixtures, at least not fully.

Even with Bundler checksums enabled? 🙂

We only have paid gems vendored for conveniece (Sidekiq/graphql-ruby Pro). But I always wished they waren’t commited to source control, because I want to treat them as external.

How is that different from installing gems? Why don’t we vendor gems then?

That part where I need to commit source code for a 3rd-party package into version control.

OK, I guess Sorbet also does dynamic typechecking then.

What would you dislike about moving those type annotations into comments? I feel like you’d still write similar amount of code, unlike with RBS header files where you need to repeat method and class definitions.

I watched the demo, and while impressive, I would like to not have a different method syntax.

Also, inline RBS supports static typechecking from what I understand, while I imagine this is only for runtime typechecking.

I also don’t like the look of those leading underscores 🙈

I haven’t personally experienced many issues with environments differing, so it’s not a problem I’m eager to have solved.

What is it about?