I have also noticed this with Sonnet, funnily enough - it's not as strong, but it's still there. But yeah, I haven't seen this with any other model so far (although I mostly use the stronger ones - maybe it's a function of intelligence?).
I don't think it's particularly effective to create a new coding agent when there's existing open-source agents (especially extremely extensible ones like Pi) that already optimize for cache hits, have far larger communities, and work for providers other than Deepseek.
I specifically use multiple different models and providers, so this wouldn't be useful for me.
And it contributes to the problem of each person vibe-coding their own, incompatible, half-baked tool in a space, instead of contributing to a small set of tools and expanding them.
I'd generally agree about Deepseek being as good as Sonnet - but I have extreme trouble with prompt compliance with V4 Pro in a way that I've never had with Sonnet. I'll tell it "find the bug, but don't fix it" or "please use this tool I just developed" and it'll ignore me a high fraction of the time.
It's bad enough that I'm working on guardrails at the harness level because prompting appears to be useless.
I don't think dismissal 1 applies anyway - even if RefTerm didn't implement, say, variable-width fonts - you could just build a terminal that uses RefTerm's fast algorithms for the common case, then falls back to the Windows Terminal's slower algorithms for the more general case.
Can you explain how screen reader support could possibly have a noticeable performance cost?
The screen reader code should be doing absolutely nothing if it's not enabled - and even if it is, I can't imagine how it could affect performance anyway. For plain text, such as a terminal, all it does is grab text and parse into words (and then the part where it reads the words, but that's separate from the terminal) - I don't see how this is any more difficult than just taking your terminal's array of cell structs, pulling out the characters into a dynamic array, and returning a pointer to that.
Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be".
The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts.
That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.
I'm eagerly awaiting the https://www.rekt.news/ writeup, which as of this moment is still missing. They have decent technical analysis, and certainly far more than the linked article.
I think that the perfect editor would use the perfect extension language...which, sadly, does not exist.
As a Lisp+Emacs user, I'm biased towards elisp, but it's definitely not perfect, having multi-decade-old baggage that holds it back. Lua has a beautiful design that is geared toward embedding, but lacking metaprogramming capabilities and things like optional typing. Python's design is ugly in many ways that the other two aren't, but it's more featureful than either of them and doesn't have elisp's warts. JavaScript has a more elegant design than Python, but a bad rep and a community that is borderline averse to performance.
There is no perfect extension language, and I'm convinced that, for fundamental reasons, there can never be.
But, I'll take an imperfect language (again, I'm biased, but I'm very bullish on a Lispy and Lua-y stuff) over none at all.
> Built with Rust. No Electron. No VimScript. No JavaScript.
Great. So, what's the extension language? Rust is utterly inadequate to be a scripting language (if you have to recompile the text editor to reconfigure it, that's a non-starter).
VimScript sucks, but it's better than literally nothing. Emacs Lisp is weird, but powerful. Python is great and everyone knows it. Lua is small, simple, blindingly fast, and literally designed to be embedded in compiled projects.
Why is there no mention of extensions or extensibility?
As it happens, I purchased the only two pieces of technology that I actually like in the past two years.
The first is the ReMarkable 2[1]. While imperfect (not open-source, support is atrocious), its utility is so high that it more than makes up for it - it actually behaves like electronic paper, and is better than real paper for my use-cases.
The second is a Dactyl-Manuform that a friend built and sold to me. It's one of the best ergonomic keyboards in existence, with the only others even able to challenge it are the Squeezebox[3] and the WARP[4]. Seriously, the DM makes almost every other "ergonomic" keyboard look like a joke, and it's physically pleasurable to type on.
I propose a new heuristic called "The HN PR Law" or something to that effect: no response from a company on a negative PR incident should be taken seriously after an article on said incident hits the front page of HN.
Given Google's track record and the ranking of this post, they'll probably reinstate the app within a few hours, and I propose that we act as if they had not - only acting on issues after they have been exposed to a massive audience signals a desire for public positive perception without any actual care for users, and users shouldn't have to go to social media to get their problems solved.
When will a correctly-implemented GC ever alter your program's functional correctness, aside from timing-related bugs that aren't fixed by manual memory management either?
I have also noticed this with Sonnet, funnily enough - it's not as strong, but it's still there. But yeah, I haven't seen this with any other model so far (although I mostly use the stronger ones - maybe it's a function of intelligence?).