Show HN: A pure-Ruby X11 terminal | Hacker News Reader

Show HN: A pure-Ruby X11 terminal

github.com

10 pointsvidarh10 comments

I use this as my regular xterm replacement... Why? Because I can.

It's pure-Ruby down to the font-renderer, and the X11-bindings.

(I also run a Ruby WM, a Ruby editor, file manager, and more, so this is just par for the course of my descent into madness)

It supports double-width and double-height text, unicode (but double-width characters may currently be rescaled down), layering fonts, special rendering of box-drawing characters (to ensure they seamlessly scale and connect, and has reasonably complete vt-100/vt-102 emulation. The whole thing is available as a Rubygem and comes with an ANSI text backend, so you can run your terminal in your terminal. The bulk was written manually, but the last few days I had Claude write a test harness to shake out a bunch of bugs, and start refactoring and cleaning up the code base (it's still full of warts).

Open articleView on HN

> This shows Rubyterm running on my Ruby based WM, running Rubyterm with a text-based-backend that renders a a terminal to text (so it can run in any terminal), running my editor Re editing the Rubyterm example. The text is rendered using the pure-Ruby TrueType font renderer Skrift, and connected to my X11 server using the Pure-X11 Ruby X11 bindings

Cool

Thanks. I just re-targeted my editor to use this code to render using the text-based-backend or optionally using the X11 backend, so now I can layer the same renderer even more times...

https://en.wikipedia.org/wiki/Terminal_emulator, not https://en.wikipedia.org/wiki/X_terminal

Languages evolve. Nobody I know goes around bothering saying "terminal emulator". The last time I touched an X terminal was 30 years ago - I have no intention of bothering with the distinction.

I just connected the dots. You're the guy who constructed a direct Ruby-to-assembly compiler some time ago, right?

Yeah, it's languished for years. I did a stint last autumn to get it to start passing more of Rubyspec, but haven't had time to take it further.

github.com/vidarh/writing-a-compiler-in-ruby

It's self-hosting apart from the GC (which is a sore spot - I really want to rewrite the GC in Ruby too), glibc for a handful of functions and syscalls, and using gas/ld to assemble and link.

No worries. My impression was, the premise of your articles was not (at least not initially) a compiler for a fullest Ruby with all of its intricacies, but rather showing a great technique how to tackle a problem. For me and few of my pals it was an inspiring eye-opener. We were coming from the 8bit era and had our hands dirty in assembly before, yet your approach showed we can do a lot of low-level stuff in a modern Unix setup.

Kudos for your work - and I guess you've had a lot of fun as well

Appreciate it. Yeah, you're right - when I started I didn't even plan on doing a Ruby compiler at all, just a compiler in Ruby. But I was also obsessing over the difficulty of compiling Ruby, and so was tempted to see how far it would get.

I'd really like to find time to pick it up again and clean it up and I'm toying with dynamic workflows in Claude now and might just have it set up one to "burn down" rubyspecs, as it did fairly well last autumn at fixing things, including adding bignum and beginnings of Regexp support.

Getting from working to usable and fast, though, would be a lot of work.

> Why? Because I can.

Always the best reason.

I find I have to specify this for some of these projects, because rewriting basic stuff like this often has a lot of people asking what the point is...

But I love small rewrites (this is <3k lines of code for the terminal itself; the font renderer is 600-700 lines or so; the X11 bindings a bit larger) as a means to explore what is really actually needed for the things I do...

Reply on news.ycombinator.com