LSH feels like it's being massively undersold here. The `grammars/` directory of helix is something like 183MB. That would be a non-starter for a lot of use cases for edit (which is already only 167kB). tree-sitter might be more powerful, but this is more than good enough, and it is orders of magnitude smaller.
I'd love to read a longer blog post that details how y'all compared existing implementations and came to the conclusion that writing your own was the best path here. This kind of attention to craftmanship is something I feel like we're desperately missing these days in software.
There's even more under the "Updates archive" expando in that post.
It was a pretty compelling prototype. But after I played with Polyglot Notebooks[1], I pretty much just abandoned that experiment. There's a _lot_ of UI that needs to be written to build a notebook-like experience. But the Polyglot notebooks took care of that by just converting the commandline backend to a jupyter kernel.
I've been writing more and more script-like experiments in those ever since. Just seems so much more natural to have a big-ol doc full of notes, that just so happens to also have play buttons to Do The Thing.
Notably this article was written based on Windows Terminal 1.18. That was before WT 1.22, which included this PR: [^1] which roughly doubled the terminal's throughput. That combined with a couple of other PRs in 1.22 made some scenarios up to _16x_ faster[^2]
It's shipped with Windows since Windows 11. Updates come via the Store (since that's a lot faster than OS updates), but it's definitely preinstalled these days
No love for Windows Terminal? I know that linux has a much richer terminal ecosystem, but WT ranks a lot higher than a wide breadth of terminal emulators on linux now. Could anyone have imagined that 10 years ago?
What complaints do you have with the Windows Terminal specifically? I can get having issues with CMD or PowerShell - they're very non-unix-y. But WT itself is probably one of the most feature-complete terminal emulators out there these days. I'd love to know what you think it's missing
Yedit actually was written by a Microsoft employee :P
It had some problems however with handling unicode (iirc). Basically, shipping yedit would have required a huge re-write of its underlying text buffer. In the end the discussions we had with Malcom concluded that just writing a new one was probably easier and more maintainable in the long run.
That is _technically_ correct (the best kind). There's some plumbing between conhost and Terminal we need to clean up before we can add it to Terminal too. We've got a branch ready, we've just got to merge a whole stack of PRs first before we can get there.
We shipped it (the Terminal) with the first versions of Windows 11. I don't think the "default terminal" feature defaulted to the new Terminal in the first win11 builds, but it should now. And you can always pick whichever terminal you want as the default terminal
Conhost and Terminal share quite a lot of code in fact. The text buffer, the renderer, the VT sequence parser - all that's the same codebase. That allows bugfixes and improvements to the the Terminal to also flow back to the vintage console (for people who still use that)
This is a great write up, thanks for sharing. I had never heard of these before, and would usually be totally against a subscription based product like that. But the idea of totally bypassing their "drm" for 1/60th the cost? Much more intriguing
I'd say waking up today to all this... negativity? was kinda a bummer. We've been working hard on something that people (myself included) have been asking for _for years_.
Like, obviously, it's not perfect out of the gate. That's fine! It was a haul enough to ship this in any form. Now that it's out there, we can make more and more improvements. One step at a time.
Sometimes, I just need a break from the internet I guess.
Happy to have the feedback! Most of those I've already fixed internally, there's just a 3-4 week delay between me checking in, and it flowing to Insiders.
For the other few things I missed: Very happy for the feedback! I've filed bugs and those'll be the first things I look at come Monday morning.
There are security implications for running elevated processes connected to unelevated console/terminal windows. "New window" mode avoids those security concerns. A secure-by-default posture seemed prudent.
I live by a one step at a time philosophy. It's better to make some incremental progress here, now, and open the door for future progress in this space too. Just like the Terminal - what we're putting out here in the first versions is just the first thing we feel comfortable with people using. We've got lots of ideas for more things to add, just, one step at a time :)
I'd love to read a longer blog post that details how y'all compared existing implementations and came to the conclusion that writing your own was the best path here. This kind of attention to craftmanship is something I feel like we're desperately missing these days in software.