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?
TBF we've actually maintained the Windows Console for the better part of 5 years and we're incredibly passionate about performance. We live and breath in the commandline. Performance has always been one of our P1 priorities, because improvements to the console have second-order impacts on the entire commandline ecosystem.
There is an engineering tradeoff though - we've only got so many devs and at a certain point you have to say "good enough for now, we'll come back to this, let's go do this other thing for now". The Terminal is faster than conhost was, and that's a good place to start, but I don't think anyone things we're done working on the Terminal, and we're certainly not done working on its perf ;)
Actually, the Windows Terminal shares a lot of its codebase with the Windows Console. The buffer, the VT parser, the renderer interface, most of the UIA implementation - that's all the same code. Improvements here to the Terminal actually help conhost.exe as well.
The UI of the Terminal is what's new, because trying to iterate on the legacy UI of conhost.exe was simply not maintainable.
And see, even you've done it here. Command Prompt is `cmd.exe`, which is different from PowerShell (`powershell.exe`), and both of those are different still from `conhost.exe`, which is the actual console window itself. cmd and powershell are "shells", which both need to run in a console, and conhost.exe is that console (which is the "terminal window" for these applications). More reading: https://github.com/microsoft/terminal/blob/main/doc/Niksa.md...
Conhost is the window that's had updates all throughout Windows 10. It's responsible for both the console subsystem, and the console UI. The UI though is the part that's largely being replaced by the Terminal. Conhost will never go away, but the Terminal is where all the action is these days.
Such is the nature of a flame war. It's also REALLY hard to take thread after thread of discussion about how this thing you built is totally shite, and not try to respond in some way.
It's hard to clearly communicate on the internet "we could do better here, we'd love some help, but you don't need to be an asshole about it". Once casey was set on his warpath, I think it was just too late.
Yea, it's been a generally shit experience. Knowing the sense of humor of the original "PhD" comment, yea, I read that as a light-hearted jest, which was definitely lost in transit. Communicating on the internet is hard. Miscommunications are easy, and this one happened to spiral quickly. It saddens me that this whole incident was used to balkanize the community rather than to work constructively together.
That's a pretty terrible interpretation of events here. Along side the "combative" phrasing was a bit of self reflection
> Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.
That post is literally not trying to shut down the conversation, it's simply reflecting on the tone of the commentator. elsewhere in the comment he even prompts for more discussion on the topic. At no point is the CoC invoked.
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.