holy fuck, you can pipe into stdin and tables render properly!

while this is quite out of schedule (i usually post every 2-3 days), today brings some peak stuff! the peakest part is at the end

firstly, i have in fact fixed tables! the issue was i was pushing the accumulated cells array to the rows array in the wrong loop. i was doing this in the loop that iterates over the cells in a row, so it was causing it to repeatedly push the same strings over and over. the fix was putting it in the loop just outside, that is, the loop that iterates over the rows in the table token!

i’ve also improved the image handling! now Image classes have the buffer property renamed to content, and has a new property called properties, which is always {}. with this, it has all the properties of ProcessedToken, so my lsp won’t complain that some property doesn’t exist on Image

speaking of ProcessedToken, its now an interface instead of a type. there’s also a new TableToken interface that extends ProcessedToken, with an alignment property. this makes it a bit easier to handle tables since the content property is narrowed. also, it seems like opentui’s tables don’t support alignment, so i might have to make a custom table function.

i also upgraded opentui from 0.5.7 to 0.5.8! i have no idea what changed, but whatever

i’ve also stopped using chalk to color my errors since the opentui console doesn’t support ansi

now the peakest part is you can pipe markdown into the program. this is pretty peak and you must agree since there’s a lot of stuff you can do with this. for example, you could render arbitrary markdown without having to create a file first!

it has a limitation though: if you’re on windows, you can’t use the interactive mode, and the rendered content is forced to print to stdout. this is because of a bug with bun. if you’re piping into the program, it’ll get the input by calling await Bun.stdin.text(), but this stops sending keypresses to opentui because of a bug in the bun runtime, so you can’t scroll down. i solved this issue (or rather, chatgpt solved this issue) by opening a read stream on /dev/tty. the issue with this is that /dev/tty doesn’t exist on windows since its not unix-like. my idea was to just, not let you do interactive mode on windows if you’re piping content to it. again, this is a bug with bun, and i’ll remove this limitation once one of the two is merged. that’s right, there’s two! here’s one for reference: https://github.com/oven-sh/bun/pull/32153

shit that was long

Changelog

• (dd07e14) Upgrade packages
• (77e6d34) Add support for piping into renderer.ts from stdin
• (1995f45) Improve image and ANSI handling, stop using chalk in errors
• (22cfacd) Improve table handling, switch some types to interfaces

pls like