Comment by tschumacher
4 months ago
My coworker recently showed me this plugin [1] that fades out all Rust code that is unrelated to the variable under the cursor. Think of it as a more powerful version of the "click to highlight all appearances" you can do in most IDEs but it actually does information flow analysis on the code.
Will Chrichton gave a talk at Jane Street about his research that led to the development of this plugin. It’s a pretty good talk:
https://www.janestreet.com/tech-talks/rust-for-everyone/
As I recall, he also explains how Rust is uniquely positioned to enable this kind of syntax formatting.
Need this for every language …
It can't. It uses ownership types in Rust to do the analysis. It can be fooled by Rust's interior mutability. Other languages don't have a type system that enables this.
If Eclipse's archaic(!) variable renaming feature for C++ can distinguish between related and unrelated variables which have the same name, you can implement this thing in almost any language.
Eclipse CDT has a real-time static analyzer for the code you're working on though. It's not as naive as it looks from a distance.
3 replies →
From thinking about it and merely looking at the gif example... I think you could actually get there via language server alone - at least mostly?
It just highlights parts that interface with a symbol, right? And that's information the language server is supposed to expose.
You'd "just" have to make a x+1 mapping to highlight anything that's touching the symbol
To be clear, I'm just speculating here and not speaking with authority on the topic. It's possible I'm missing something which makes this approach infeasible in practice
1 reply →
You merely explain why you can't copy the implementation strategy.
But that says nothing about providing the same value to the user in other languages via different means.
4 replies →
It's not exactly rare to avoid mutability/use a functional style in application code, and even in mutable code, IME aliasing is rare. In some ways Rust's rules are kind of a formalization of what was already good practice in C. Variable scope is also usually small. Turns out things that are easier for the computer to analyze are also easier for people to analyze, so it's long been good practice to structure your code in easy to analyze ways.
LLMs are getting better and cheaper. It's ridiculous overkill for the task, but they could potentially do something like this and more sophisticated versions highlighting related code on other dimensions.
3 replies →
Shouldn't be too difficult for C# with Roslyn
1 reply →
Oh wow, this is actually useful
And, so, does syntax highlighting interfere in that? No.
The information channel is shareable.
That’s basically the first paragraph of the article.
I don't see that; it doesn't acknowledge that the channel can be multiplexed and thus isn't wasted by dedication to syntax.
1 reply →
This sounds good but if you need it, you probably can and should refactor the code.
You know what would be great for refactoring the code? Some way to easily see what parts reference the variable you’re trying to refactor.
Unless you have spaghetti code or have built an abstraction tower, a variable is probably scoped/namespaced neatly. Often, it's just a quick grep to find it. In Emacs, if a variable is only used within a file, you can just `M-x occur` and do the editing there. Where those tools fail, is when you have ecosystems that tries to be clever (JavaScript with its transpilers, Java with its annotations)
3 replies →
Yes, but not everyone uses features like this to make code easier to read. Instead, features like this make less readable code become tractible. The same can be said about autocomplete and documentation popups too. I remember Uncle Bob saying once that his 5 line function limit was facilitated by an editor feature he had that could easily display the code of functions that are called. So it stands to reason that the recommendation should be 25 lines if you don't have such a feature, I think. We don't need to go back to Hungarian notation but certainly using a bunch of fancy features to read the code makes it inherently less readable on the surface level (unless you are very anal and also self-aware and can stick to clean principles).
I'm surprised my comment was downvoted so bad for making an astute observation. It happens to me all the time. A lot of the users of this site suck.
4 replies →