It’s in a closed beta stage. If you’re friends with Jonathan Blow or somehow catch their attention he might give you access, entirely at his discretion.
I get why he did this for the first couple years. But continuing with this development model for over 10 years made me realize Jai is and will likely always be closed source software.
Really interesting. I love the fact that it is built with practical utility in mind and that it negates so many dogmas that other languages are built on.
Assuming 60 FPS is responsive enough, you can measure how many bytes you can copy with memcpy in 16ms and that should give you an idea of when this editor will start feeling slow when editing large files.
This is ambitious! Written in Jai, a brand new programming language not even releases publicly yet. Supporting Linux/macOS/Win from the start. Rendering a GUI instead of a text UI. Curious to see where this will go.
Ooh! This is the first Jai codebase I’m ever looking at. Exciting!
Not to be confused with another simple and fast text editor:
https://github.com/jamii/focus
The author credited that project:
Missed that, thanks!
Wait, is Jai available now?
It’s in a closed beta stage. If you’re friends with Jonathan Blow or somehow catch their attention he might give you access, entirely at his discretion.
I get why he did this for the first couple years. But continuing with this development model for over 10 years made me realize Jai is and will likely always be closed source software.
Doesn’t seem like there’s a public release of it yet.
I’ve been using Zed lately and enjoying it.
I never heard about the jai language which this is written in. I googled it and found this introduction. https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
Really interesting. I love the fact that it is built with practical utility in mind and that it negates so many dogmas that other languages are built on.
I wonder what they mean by very large files….
And for that matter what they mean by fast…
I read the source code a little bit. It looks like the text is stored as a flat byte array (not sure which encoding) + a separate array for offsets of line starts.
So editing is
O(n)wherenis the size of the buffer.For example, here’s the char insertion. It calls
insert_string_raw, which callsarray_insert_bytes_at, which shifts the rest of the buffer and inserts the given bytes.Edits also mark the buffer as “dirty” and before redrawing it does a scan over the
bytesarray to re-generate the line starts.Assuming 60 FPS is responsive enough, you can measure how many bytes you can copy with
memcpyin 16ms and that should give you an idea of when this editor will start feeling slow when editing large files.I don’t know if there are other inefficiencies.
This is ambitious! Written in Jai, a brand new programming language not even releases publicly yet. Supporting Linux/macOS/Win from the start. Rendering a GUI instead of a text UI. Curious to see where this will go.
[Comment removed by author]
[Comment removed by author]