The technical challenge is that a Crystal program needs to be inspected as a whole. Simplified, changes in location A can have effects on some completely unrelated location B. That makes it hard to cache intermediary results and a semantic analysis needs to cover the entire program (including the standard library), not just the files that were changed since the last time.

This applies to the responsiveness and memory consumption of the language server as well as the regular compilation process. So this is an important topic, and we're working on improvements. It's a complex topic, but there are some ideas.

This is the same problem with Ruby, Python. or any interpreted language.

What most LSPs do is approximate it rather than worry about perfection and deliver nothing.

I totally agree with this idea, Crystal core member seems to think less of it from a beginner programmer's perspective.

Good to know. I've got zero emacs skills and I'm on vscode and nothing works there. From what I understand the lack of type info until the whole program is compiled creates this issue.