BLURP.md

Unicode encoding needs 4 Bytes per char within st, and I nearly never need unicode chars in the terminal.

Same for rgb colors. Stripping them of st spares 6 Bytes per Glyph.

Before the changes every Glyph needed 15 Bytes, now it's 4 Bytes. I personally prefer having a quite big (10.000 lines or more) scrollback buffer, so this is a factor. Resulting in a faster and more responsive terminal emulation.

>(..I'd propose, unicode isn't needed for system administration/ development at all. You are going to get into all sort of troubles, when, e.g., you'd be naming files and directories in the root fs using unicode characters. Furthermore, let's assume, there are, say, 100.000 instances of st running. Now, on the world. Multiply this with, umm, 10 MB, multiply with cpu cycles of 100.000 (swapping, and so on), and . It's not theoretical anymore. Ok. The calculation might be a little bit too easy. Admittedly, you shouldn't multiply memory and cpu cycles. Anyways, my point is valid. And there is the computing time to add, generated by typos. Adding a unicode character in the wrong script could create.. uuh never mind. But it's a good reason to stick to KISS (keep it simple, stupid..) principles. Murphy's law will strike, anyways. That's the law..)

So, in my quest to slim down all programs I'm using, I'm about to strip unicode and utf8 support.

Yet I managed to get a virtual memory footprint of around 8MB. Ok. Added all patches, and with the current history of 10k lines, it's at 12MB. (>20MB before) I'm always keeping more than 10 terminals open, so that sums up. Every Glyph (char at the screen, with attributes and colors) now needs 4 Bytes. ( 15 Bytes before stripping unicode and rgb)

The smaller memory footprint also pays out in a more responsive system overall, improving st's speed as well. (3x here) Ok. I tried hard, to get "benchmarks", the removed unicode support doesn't profit of. Still, this shows up with a gain of 2x.

I checked several emulators, closest in terms of performance would be urxvt. However, testing and comparing more, the speed of urxvt is given by a (neat) trick. When dumping many chars into the terminal, eg. with cat, the screen doesn't show every single character. It's more sort of an animation, showing only enough chars to give the perception of a continous scrolling terminal. When confronted with, e.g., a dd if=data bs=1000; this cheat doesn't work anymore, dumping the data takes (depending on the size, etc) up to 20times longer. st seems to be the fastest terminal emulator available.

The (pseudo) rgb color support is stripped. Saving 6 Bytes per glyph. There still is the option to have "rgb" colors via modifying the indexed 256 color palette, the default is the ("standardized") xterm 256 color palette. This slims down the memory usage of the colors from 8 Bytes to 2 Bytes per glyph.

;) To quote Bill, 256 colors ought be enough for everyone. (Am I confusing something..?..)