Spending a lot of time building tools inspired by and using ASCII nowadays...
graph-easy.online printscii.com
ASCII-Driven Development
41–50 of 97 posts
Re: ASCII-Driven Development
#42What tools can we actually use to draw ASCII manually if desired? None are mentioned. E.g I made https://cascii.app for exactly this purpose.
Monodraw for Mac is my favorite. I'm a customer. $10 license. https://monodraw.helftone.com/
Re: ASCII-Driven Development
#43Earlier quoted context omitted.
Emojis mixed with ASCII-era characters are hard to get right. Some terminal emulators get it right nearly all the time (e.g. Ghostty, which has had a lot of thought and effort put into getting it right) and yet there are still open issues in the Ghostty repo about inconsistent character width. There are just so many corner cases that it's hard. That said, the edge alignment is, I believe, caused by the fact that LLMs…
They are treated like double width characters. All it takes is a Unicode aware layout algorithm that tracks double width codepoints. The tricky part is older single width symbols that were originally not emoji and now have ambiguous width depending on the terminal environment's default presentation mode.
The other tricky part is emojis made up of multiple codepoints with zero-width joiner characters and variation selectors, or other symbols. E.g. is made up of U+1F1FA REGIONAL INDICATOR SYMBOL LETTER U followed by U+1F1F8 REGIONAL INDICATOR SYMBOL LETTER S, or (which should render as a single symbol, a burning heart / heart on fire), which is made up of the four-codepoint sequence U+2764 HEAVY BLACK HEART, U+FE0F VARIATION SELECTOR-16, U+200D ZERO WIDTH JOINER, and U+1F525 FIRE but should only render in one double-width block. Then there are even more complicated sequences like , which again should render in a single block but are made up of six(!) codepoints: U+1F469 WOMAN, U+200D ZERO WIDTH JOINER, U+2764 HEAVY BLACK HEART, U+FE0F VARIATION SELECTOR-16, U+200D ZERO WIDTH JOINER, and U+1F468 MAN.
The number of codepoints never did correspond exactly to the number of fixed-width blocks a character should take up (U+00E9 é is the same as U+0065 e plus U+0301 COMBINING ACUTE ACCENT, so it should be rendered in a single block but it might be one or two codepoints depending on whether the text was composed or decomposed before reaching the rendering engine). But with emojis in play, the number of possibilities jumps dramatically, and it's no longer sufficient to just count base characters and ignore diacritics: you have to actually compute the renderings (or pre-calculate them in a good lookup table, which IIRC is what Ghostty does) of all those valid emoji combinations.
P.S. The Hacker News comments stripped out those emojis; fair enough. They were, in order:
- a US flag emoji (made up of two codepoints) - a heart-on-fire symbol (two distinct symbols combined into a single image, made up of four codepoints total) - a woman and a man with a heart between them (three distinct symbols combined into a single image, made up of six codepoints total)
Re: ASCII-Driven Development
#44A really interesting article, and I'm likely to give it a shot a work. I'm grateful for it, and yet I found it difficult to get through because of a sense of "LLM style" in the prose. I won't speculate on whether the post is AI-written or whether the author has adopted quirks from LLM outputs into their own way of writing because it doesn't really matter. Something about this "feeling" in the writing causes me discom…
I also have this reaction to this type of prose, for better or worse. It's depressing to see so much of it shared. It makes me want to (in a friendly manner!) grab the author and tell them to write in their own voice, damn it.
Re: ASCII-Driven Development
#45This is a tangential point (this post is not really about TUIs; sort of the opposite) and I think lots of people know it already but I only figured it out last week and so can't resist sharing it: agents are good at driving tmux, and with tmux as a "browser", can verify TUI layouts. So you can draw layouts like this and prompt Claude or Gemini with them, and get back working versions, which to me is space alien techn…
This is spot on, I understand very little about how terminal rendering works and was able to build github.com/agavra/tuicr (Terminal UI for Code Review) in an evening. The initial TUI design was done via Claude.
Re: ASCII-Driven Development
#46I really like this idea, but I get distracted when the vertical bars don't line up!
+--------+
| |
| ASCII! |
| |
+--------+Re: ASCII-Driven Development
#47Earlier quoted context omitted.
Would love to hear more about this approach.
It's actually really easy in Claude Code. Get a TUI to the point where it renders something , and get Claude to the point where it knows what you want to render (draw it in ASCII like this post proposes, for instance). Then just prompt Claude to "use tmux to interact with and test the TUI rendering", prompt it through anything it gets hung up on (for instance, you might remind Claude that it can create a tmux pane wi…
Can you explain tmux's contribution here? I'm confused why this process wouldn't work just the same if CC directly executed the program rather than involving tmux. Are you just using tmux to trick the program under test into running its TUI instead of operating in a dumb-stdout mode?
Re: ASCII-Driven Development
#48A really interesting article, and I'm likely to give it a shot a work. I'm grateful for it, and yet I found it difficult to get through because of a sense of "LLM style" in the prose. I won't speculate on whether the post is AI-written or whether the author has adopted quirks from LLM outputs into their own way of writing because it doesn't really matter. Something about this "feeling" in the writing causes me discom…
I've had too many LLMs tell me that software product ABC can do XYZ, but when I actually read the ABC documentation I discover that that hallucination was the opposite of reality: the docs say "we cannot do XYZ yet but we're working on it." So for me, the question at the back of my mind when I encounter an obviously LLM-generated article is always, "So which parts of this article are factually correct, and which part…
I should add that for me, when it comes to LLMs telling me "facts" that are the opposite of reality, "too many" equals ONE or more.
Re: ASCII-Driven Development
#49Earlier quoted context omitted.
It's actually really easy in Claude Code. Get a TUI to the point where it renders something , and get Claude to the point where it knows what you want to render (draw it in ASCII like this post proposes, for instance). Then just prompt Claude to "use tmux to interact with and test the TUI rendering", prompt it through anything it gets hung up on (for instance, you might remind Claude that it can create a tmux pane wi…
Can you explain tmux's contribution here? I'm confused why this process wouldn't work just the same if CC directly executed the program rather than involving tmux. Are you just using tmux to trick the program under test into running its TUI instead of operating in a dumb-stdout mode?
It allows Claude to take screenshots and generate keyboard inputs. It's like TUI Playwright.
Re: ASCII-Driven Development
#50Author here. High-level: - Problem: AI UI generators are high-fidelity by default → teams bikeshed aesthetics before structure is right. - Idea: use ASCII as an intentionally low-fidelity “layout spec” to lock hierarchy/flow first. Why ASCII: - forces abstraction (no colors/fonts/shadows) - very fast to iterate (seconds) - pasteable anywhere (Slack/Notion/GitHub) - editable by anyone Workflow: - describe UI → generat…
The problem with ASCII-driven development for me is that emoji ruin the alignment. It’d be nice if they could be forced into monospaced. Emoji aren’t ASCII so maybe that’s the problem too.
Unicode emojis aren’t ascii .
Long before Unicode points were assigned we were using emojis in text communication in email and sms.
you can always be quite expressive with ones like :) :D :-( or even ¯\_(ツ)_/¯ - although not strictly ASCII.