Wilfred

It seems to be a more structured representation of the type. Normally in LSP you'd have a plain string or markdown that you render in the IDE, but nothing that you can analyse structurally.

It's a shame it's not just an LSP extension though, or a feature in a newer LSP version. LSP is maintained by Microsoft engineers.

If I've understood this interesting workflow correctly, there's two major components.

streamdown: a markdown renderer for the terminal, intended for consuming LLM output. It has affordances to make it easier to run the code snippets: no indentation, easy insertion in the clipboard, fzf access to previous items.

llmehelp: tools to slurp the current tmux text content (i.e. recent command output) as well as slurp the current zsh prompt (i.e. the command you're currently writing).

I think the idea is then you bounce between the LLM helping you and just having a normal shell/editor tmux session. The LLM has relevant context to your work without having to explicitly give it anything.

In `use foo::bar; use bar::foo;`, am I importing an external crate called foo that has a submodule bar::foo, or vice versa?

This bit me when trying to write a static analysis tool for Rust that finds missing imports: you essentially need to loop over imports repeatedly until you reach a fixpoint. Maybe it bites users rarely in practice.

> Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure out how to explain it better, for years now.

The module system in Rust is conceptually huge, and I feel it needs a 'Rust modules: the good parts' resource to guide people.

(1) There are five different ways to use `pub`. That's pretty overwhelming, and in practice I almost never see `pub(in foo)` used.

(2) It's possible to have nested modules in a single file, or across multiple files. I almost never see modules with braces, except `mod tests`.

(3) It's possible to have either foo.rs or foo/mod.rs. It's also possible to have both foo.rs and foo/bar.rs, which feels inconsistent.

(4) `use` order doesn't matter, which can make imports hard to reason about. Here's a silly example:

use foo::bar; use bar::foo;

(Huge fan of your writing, by the way!)

tree-sitter has first class support for parsing errors as ERROR nodes in the output tree. I treat these as just another atom in the s-expression.

In practise I haven't noticed any issues yet. I suspect that difftastic doesn't see many syntax errors because users have fixed most of them by the time they run the diff. When you look at diffs of committed code you hopefully have no parse errors at all.

The tree-sitter parsers could still reject valid code I suppose. I worry slightly more about the parsers getting precedence/associativity wrong, but it would be hard to construct an example that produce identical parse trees due to incorrect precedence.

Side-by-side diff displays work really great in a browser. You usually have more screen real estate, and you can offer a responsive UI.

Thanks for the feedback! I'll look to clarify the wording here. The failed example was a real output that difftastic gave in early versions.

I agree that the classic red/green colour scheme of diffs isn't great for colourblind users. I've asked a few colourblind developers and they were happy with terminal ANSI colours (which is what difftastic uses), because they can configure each colour individually.

Yep, that's correct. Difftastic is only a syntactic analysis, although it often makes the semantic intent clearer.