I don't know enough about Zig to explain it, but there is more to ReleaseSafe than checks and panics. ReleaseSafe also clears memory that no longer has an owner (I might be describing that wrong, that is just how I understand it). I found this out with a rendering issue recently.
The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.
Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.
The vast majority of my company's enterprise plan use is through Claude Code even though we have access to the API and could be using OpenCode instead.
I don't fully agree with the premise that they intentionally increase system prompts, but the enterprise plan usage is going to make that a huge income for Anthropic.
I agree! It seems like their work on the iOS app would bring them a lot closer to web app support as well. In the iOS tracking issue, they say the main changes are moving to Kotlin Multiplatform and Compose Multiplatform, which both support web as a target.
Well, sort of. That'd be very bluesky. What's closer, actually, would be a desktop version, or rather, a version for Linux mobile like postmarketOS (would run like a desktop app in a JVM, but for a mobile target, the layout and UX wouldn't need to be changed.
If anyone is looking into ergonomic keyboards, look into a layout other than Qwerty as well. I swapped to the Corne and Colemak-DH at the same time a few years ago. The Corne is beautiful, but I would say swapping to Colemak-DH provided much more ergonomic benefit for me.
I love my Corne but I never use it any more because I have to switch to my laptop keyboard too often. I am still able to use an ergo keyboard layout on both, so even when I can't use an ergo keyboard, it is still very comfortable to type.
I tried probably 10 keyboards in a very short period when I had wrist pains. The Glove80 completely solved it for me and I never have pains anymore. I would rank from highest importance to lowest:
- Regularly exercise, including proper exercise for your hands/arms.
- Height-adjustable desk + good chair, so that you can micro-tune the height to have straight wrists, etc. It should probably be electrically adjustable, my experience is that most people do not properly set the height if it's more effort to change height.
- An ergonomic keyboard. For me, it has to be column-staggered, split, with thumb keys and a key well. I have reviewed some flat keyboards after switching to key well boards, but discomfort comes back after a few days to weeks.
- A keyboard layout. So, this is the part where I disagree with you. Switching to non-QWERTY is maybe the last 5% of optimization. There is one catch though: an alt layout becomes more important when switching to split column stagger, since you cannot alt-finger as easily and the very frequent letters T/N are in a bad position on columnar boards.
> 20% (35 chars) of screen space permanently wasted on a always on file browser
That is toggleable. Cmd+B on Mac. I usually keep it closed, but it's just a shortcut away when I need it.
> 4% (7 chars) of screen space permanently wasted by line numbers
You can disable that in the settings with:
"gutter": { "line_numbers": false }
> 2.7% (5 chars) of screen space taken up by a gutter
You can also disable the other items in the gutter to free up all of that space.
> So 27% of screen space effectively dead 99% of the time.
You can also press shift+esc at any time to toggle a fullscreen pane of whatever you are working on when you need more space without affecting your editor's state. I don't know the name of that action, I actually found that accidentally.
Edit: I forgot to mention, you can actually disable the tab bar now too if you want even more space. You would just need to rely on the tab switcher feature or file search to move around.
I would damn hope you can configure/disable this. But why is it the default?
And if the answer is "discoverability" then where is the default-on fuzzy find, default-on command palette, default-on context menu, etc?
My point was not to claim Zed was bad because I had the ignorant misapprehension that it was incapable of being cleaner, my point was to ask why people desire such a cluttered workspace by default? Most people I see using these editors _don't_ disable all this clutter.
If I had to guess, it's because terminals don't know what a cursor is. From the terminal's perspective, it is just told to print a solid blinking block at a certain location. Neovide knows what the cursor is because it is communicating directly with Neovim.
A terminal could do this, but there would need to be direct integration into Bash, ZSH, etc.
Terminals do have a concept of a cursor (there are dedicated control sequences for cursor management). There's no fundamental reason a terminal emulator couldn't implement an animated cursor like this, my guess as to why no one has done it is simply that it's not a very commonly requested feature.
Another problem is that the cursor moves while the screen is buffer is being rendered. The location is only really known once the cursor settles in the same place for some time, which is unacceptable in terms of latency.
Yeah true, maybe could be done with heuristics though - in nearly every case, there's only one single blinking block, which is the cursor. However, not everyone has their cursor configured to blink, and there are cases where there are other blinking blocks. Not sure how to deal with that...
The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.
Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.
This is the commit where I fixed the issue: https://github.com/quot/donut/commit/8fff107e76278c4bf55007c...