This is pretty nice if you have an editor with block mode (like vim) and you are faster with a keyboard than a mouse (most programmers). It integrates well with text based version control and degrades gracefully in that users who don't have the tools and are just looking at the source can probably still read it, and even edit it.
It would be an improvement for the page that HN links to if the HTML snippet was surrounded by <body></body> so it worked out of the box.
Tips:
Don't use underscores for horisontal lines - use dashes (minus signs).
A vertical arrow that points at a text will collide with the text unless you add a blank line.
Rounded corners are nice. You get these by using . (period) or ' (single quote) instead of + (plus) to join lines. Use period to join to a vertical line below the horizontal line, and single quote to join to a vertical line above the horizontal line.
Hi! This is interesting and I plan to use it for work. Today.
In answer to my above inquiry:
It looks to me like this section causes consecutive 'v's to be interpreted as text; it might be nice to carve out v's or give alternative glyphs for down arrows or something:
I find ASCII diagrams to be the opposite of Markdown. Markdown isn't perfect and so that is where extensions come into play, but ASCII diagrams are more like man pages. I think ideally a diagram markup software would use YAML or some other similar convention to show hierarchy while still be readable. Typing and editing ASCII diagrams by hand is simply not convenient.
The problem with ascii diagrams is that it is difficult to edit. Say you want to move that resistor in the circuit shown in the article. You could use something like Monodraw to combat that, but then I just end up using good ol' power point. There are only handful of instances when ascii diagrams are useful, may be like an IETF proposal.
Emacs and Vim have rectangle-editing commands, these are essential for reasonably convenient editing.
They're so useful, everyone should know them anyway: Need a column of '//' rather than '/* <long_comment_block> */', or vice-versa?. One click-drag and 4-5 keystrokes will do it.
I couldn't get the demo to work without wrapping head and body tags around the appropriate sections. But once I got past that hurdle, it was easy to get some pretty nice pictures drawn. Thanks for the program!
Ha, interesting! Any chance you have a link handy with the problem? Can you expand on what you mean by "head and body tags around the appropriate sections"?
This is very slick!
Regard to editability of text diagram, brainstorming here: it would be cool to have two-way convertibility between text diagram and svg diagram. so users can use drag and drop like interaction to edit the svg diagram, and convert back to text diagram, so it has the best of both worlds.
I guess roughly this idea already exists — there is program that converts image to ascii, but it lacks precision, as in the ascii to svg and then back to ascii would yield to different set from the starting point.
I like this, but - in what contexts will typograms be accepted and rendered?
For example, email clients (e.g. Thunderbird) have not even bothered to let us use markdown for email. flowed-format text is about the most you can get out of them for now.
My desktop text editor, KeenWrite[0], allows referencing variables within the main document text and figures. KeenWrite uses Kroki[1] to provide a wealth of diagram formats. In the screenshots[2], a Graphviz-based family tree is shown that uses character names sourced from an external YAML file. Those same variables can be used when writing prose. Change the variable in a single location and the family tree is updated and rendered immediately.
You can't do that with Google Docs, Lucid Chart, Word, OpenOffice, Scrivener, etc.
That's precisely it. I wrote down a bit more down below.
"Why is it better to write diagrams by hand rather than use a tool (e.g. inkscape, google docs) and export as SVG?
Because it requires everybody that wants to edit the diagram to (a) use the same tool and (b) have access to the original source file (e.g. the google doc)."
for what it's worth, svgs are their own source file, and can typically be edited using any vector editor. I work on a project with several people who regularly trade and collaborate svg's made with inkscape and adobe illustrator without issue. It's possible you meant export as a png or some other non-vector format?
It has a built in editable fallback. If you link a LucidChart it can disappear. If you screenshot it, it’s uneditable. If you have a markup based solution, it shows best if everything is working, but if the renderer is broken you still have a working editable ASCII diagram.
I tried using this for the control flow diagrams in V8's regexp implementation, which are documented with ASCII art in jsregexp.cc Results are here: https://twitter.com/erikcorry/status/1548954799290421249
This link explains it better than the page HN links to: https://code.sgo.to/2022/06/20/typographic-diagrams.html
It would be an improvement for the page that HN links to if the HTML snippet was surrounded by <body></body> so it worked out of the box.
Tips:
Don't use underscores for horisontal lines - use dashes (minus signs).
A vertical arrow that points at a text will collide with the text unless you add a blank line.
Rounded corners are nice. You get these by using . (period) or ' (single quote) instead of + (plus) to join lines. Use period to join to a vertical line below the horizontal line, and single quote to join to a vertical line above the horizontal line.