Comment by messh
1 day ago
Anchor based editing requires injecting new anchors to the context, and dirac does so via a diff. So how is this more efficient (token-wise) than search and replace?? Even at a single token per hash. Also, code is read more than written so these just add up. I experimented once with stable anchors, albeit longer than a single token, and found it a downgrade.
My conclusion is that the efficiency dirac sees comes mainly from showing file skeleton by default
I'm not sure one way or another but I've been using a related tool called Tilth by another poster here. It doesn't do anchor-based editing, but it does do syntax-aware search and will e.g. report the line range for function definitions, provide file outlines with line numbers on a file name match, etc.
https://github.com/jahala/tilth
This seems really good...going to test it :)
ohh this is really nice :) testing it
I have six patches that I will at some point upstream, the main bug/surprise is the .gitignore behavior is not what's documented, but even without it seems to work quite well.
> My conclusion is that the efficiency dirac sees comes mainly from showing file skeleton by default
how hard do you think it would be to bring this optimization to oh-my-pi and opencode? I am testing dirac and it's very cool but the tooling isn't there yet comparing to oh-my-pi in terms of UX.
Would love some more feedback on this. Where do you think are major gaps?
Thinking back, I might have jumped the gun here. I can't objectively evaluate UX without spending more time with the tool. I'll try to daily drive it a bit before I can form an opinion.