Well it's a helluva lot faster to make for one. For two, just about everyone knows how to navigate in vscode by now. Reducing the barrier of entry has obvious advantages.
I just opened the app to see what else I can bring up, and while clicking through UI I noticed I had some crappy key bindings extension installed, which apparently caused many of my annoyances.
I've probably installed it very long ago, or even by accident.
For example, I was always annoyed that open file/directory shortcut (one of most common operations) is not assigned and requires mouse interaction -- fixed by disabling the extension.
Go to file shortcuts does something completely different -- fixed by disabling the extensions.
I likely won't adopt Cursor as my main IDE/Editor, but it's miles better than I thought just an hour ago.
Not the person you asked, but I hate how it screws up keyboard shortcuts.
It overrode the delete line shortcut with its own inline chat one, for example.
Decided to ditch it for claude code right after that, since I cannot be bothered to go over the entire list of keyboard shortcuts and see what else it overrode/broke.
I've found that annoying too, but you can always rebind them as you wish. It's only a few new keybinds that get in the way of my muscle memory.
That said I also have moved to CLI agents like Claude Code and Codex because I just find them more convenient and, for whatever reason, more intelligent and more likely to correctly do what I request.
> just about everyone knows how to navigate in vscode by now.
I don’t know and honestly I hate the assumption of the software industry that everyone knows or uses vs code. I stuck to sublime for years until I made the switch to Jetbrains IDEs earlier this year.
I quickly looked up the market share and VS code seems to have about 70% which is a lot but the 30% that don’t use it is not that small of a number either.
Like I get it it’s very popular but it’s far from the only editor/IDE people use.
These new editors are trying to differentiate themselves via their AI features. Working on the core editor may waste resources that could have been better spent improving the AI features.
Until someone finally figures out that we need to rethink editors from the ground up to support different sort of operations and editing experience, to better facilitate LLMs doing work as agents.
But we're probably 1-2 years away from there still, so we'll live with skinned-forks, VSCode extensions and TUIs for now.
It's actually weird to me how none of the big players put their money where their mouth is and vibe coded a new IDE built from the ground up for this paradigm shift regardless of tech stack.
Zed team is writing their own in-house GUI stack [1] that leverages the computer's GPU with minimal middleware in-between. It's a lot of work short-term but IMO the payoff would be huge if they establish themselves. I imagine they could poke into the user-facing OS sector if their human-agent interaction is smooth. (I have not tried it yet though)
I am very sensitive to input latency and performance but after comparing Zed and VS Code for a while I really couldn't find any reason to stick with Zed. It's been a year or so since I last tried it but VSC just lets me do way more while still, IMO, having a nice, clean UI. I never notice any performance or key input latency with VSC.
> I wonder why they are not trying to fixup something extremely complex that only a handful players managed to get right using gui stacks made with only mobile in mind that are desperately trying to catch up to desktop now
It's a good tool. However, last I checked, it was not possible to run it in a one-shot stateless fashion, like, passing it a list of music files so it auto-fetches album art, lyrics and updates the very same input files.
> Relatedly, the -q (quiet) option can help with large imports by autotagging without ever bothering to ask for user input. Whenever the normal autotagger mode would ask for confirmation, the quiet mode performs a fallback action that can be configured using the quiet_fallback configuration or --quiet-fallback CLI option. By default it pessimistically skips the file. Alternatively, it can be used as is, by configuring asis.
Beets with this flag works relatively well for me when wrapped in a shell script, but I have spent a lot of effort trying to make it actually non-interactive.
I'm still not totally sure I got all the certainty thresholds right, I still sometimes get unexpected behavior when using Beets this way, so I agree that the non-interactive experience is lacking.
Do other editors and IDEs bundle-in these external language servers? I don't think so, unless they are specifically tied to the language like Eclipse or PyCharm
Binaries for dynamic libraries of tree-sitter (usually compiled with C compiler) would be smaller than that. For example this [1] .so bundle for 107 different grammars is ~137 MiB.
Unless by "compiled in", some in-lining of the C code into Rust codebase is meant.
Thanks! Fixed that example. (In fish shell that I use, it didn't need those quotes that's why I didn't catch it)
>there are still missing expressions, such as "add up", "a couple", etc.
Googling "pronounce add up" does not show the google short answer box for me. Aside from that, the heuristic method I used may miss some words since it's not quite clear to me how the naming scheme works in that static stash. The 2024 stash is more straightforward but as I mentioned in readme, it sounds synthetic to me.
> I guess this is for when you're knee deep in terminals?
One can use it directly in terminal or it can be used as a dependency tool in other scripts similar to the way other UNIX tools are used. For example I use it as a pronunciation player in my dictionary dict-master [1]. It's a shell script too.
Another example (run two times so it uses the cache the second time):
echo this unix pipeline is poor man text to speech | xargs -n 1 gsay
I wonder why they are not trying to fixup something based on their own GUI stacks like Flutter or Compose Multiplatform.
It seems only Zed is truly innovating in this space.