Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
endbasic
BASIC environment with a REPL, a web interface, a graphical console, and RPi support written in Rust
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
nice! probably magenta on a red background is undesirable, though; maybe switch to colors with better contrasts
i hate x11 visuals and in https://gitlab.com/kragen/bubbleos/blob/master/yeso/yeso-xli... i just assume that everything is 32-bit bgra. i need to get around to fixing that at some point
what do you think an idiomatic ruby binding for yeso would look like? so far i only have lua, c, and python bindings. my ruby experience is both limited (only a few thousand lines of code) and over a decade ago
I wrote a small terminal emulator a while ago to have a portable terminal for my terminal based game. It's very specific but I had great fun with it.
https://github.com/bigjk/crt
FWIW, I wouldn't try to parse escape sequences "directly" from the input bytestream -- it's easy to end up with annoying bugs. Longer-term it's probably better to separate the logic e.g.:
- First step (for a UTF-8-input terminal emulator) means "lexing" the input bytestream as UTF-8 into a stream of USVs, which involves some subtleties (https://github.com/mobile-shell/mosh/blob/master/src/termina...).
- Second step is to run the DEC parser/FSM logic on the sequence of USVs, which is independent of the escape sequences (https://vt100.net/emu/dec_ansi_parser ; https://github.com/mobile-shell/mosh/blob/master/src/termina...).
- And then the third step is for the terminal to execute the "dispatch"/"execute"/etc. actions coming from the FSM, which is where the escape sequences and control chars get implemented (https://github.com/mobile-shell/mosh/blob/master/src/termina...).
Without this separation, it's easier to end up with bugs where, e.g., a UTF-8 sequence or an ANSI escape sequence is treated differently when it's split between multiple read() calls vs. all in one call.
I can confirm that writing a terminal is fun, for the reasons mentioned in the article: it’s easy to get “self-hosting”, but then the possibilities are endless :)
In my case, this was about creating the terminal for EndBASIC (https://www.endbasic.dev/). I wanted to mix text and graphics in the same console, so I had to ditch Xterm.js and create my own thing. It was really exciting to see graphics rendering mix with text “just fine” when I was able to render the first line.
No current version, but I'm preparing it. But actually, to see a really ridiculously minimalist start, this was my starting point, which used a tiny X extension to do the X rendering (though it optimistically included a dummy class intended to be the start for the Ruby X backend). It's awfully limited, and awfully broken, but it shows how little it takes to be able to start writing:
https://github.com/vidarh/rubyterm
It's totally useless for anything other that testing or expanding on, but it was the starting point for the terminal I now run every day, and I'll be updating that repo as I clean up my current version at some point.
The current version uses this for a pure Ruby (no Xlib) X11 client implementation:
https://github.com/vidarh/ruby-x11
And this pure-Ruby TrueType font renderer (I did the Ruby conversion; the C code it's based on was not mine, and is a beautiful example of compact C - look up libschrift):
https://github.com/vidarh/skrift
No current version, but I'm preparing it. But actually, to see a really ridiculously minimalist start, this was my starting point, which used a tiny X extension to do the X rendering (though it optimistically included a dummy class intended to be the start for the Ruby X backend). It's awfully limited, and awfully broken, but it shows how little it takes to be able to start writing:
https://github.com/vidarh/rubyterm
It's totally useless for anything other that testing or expanding on, but it was the starting point for the terminal I now run every day, and I'll be updating that repo as I clean up my current version at some point.
The current version uses this for a pure Ruby (no Xlib) X11 client implementation:
https://github.com/vidarh/ruby-x11
And this pure-Ruby TrueType font renderer (I did the Ruby conversion; the C code it's based on was not mine, and is a beautiful example of compact C - look up libschrift):
https://github.com/vidarh/skrift
No current version, but I'm preparing it. But actually, to see a really ridiculously minimalist start, this was my starting point, which used a tiny X extension to do the X rendering (though it optimistically included a dummy class intended to be the start for the Ruby X backend). It's awfully limited, and awfully broken, but it shows how little it takes to be able to start writing:
https://github.com/vidarh/rubyterm
It's totally useless for anything other that testing or expanding on, but it was the starting point for the terminal I now run every day, and I'll be updating that repo as I clean up my current version at some point.
The current version uses this for a pure Ruby (no Xlib) X11 client implementation:
https://github.com/vidarh/ruby-x11
And this pure-Ruby TrueType font renderer (I did the Ruby conversion; the C code it's based on was not mine, and is a beautiful example of compact C - look up libschrift):
https://github.com/vidarh/skrift
I really should just reproduce that output in its entirety for direct comparison.
If it does not produce pixel for pixel identical output it's a bug. But here is the first pass of code that uses the same approach to integrate it with X and use Xrender to output the rendered glyphs:
https://github.com/vidarh/skrift-x11