ASCII art for semantic code commenting
asciiflow.com
asciiflow.com
─ │ ┌ ┬ ┐
┄ ┆ ├ ┼ ┤ ╲ ╱
┈ ┊ └ ┴ ┘
━ ┃ ┏ ┳ ┓ ┏ ┯ ┓ ┏ ┳ ┓ ┏ ┯ ┓
┅ ┇ ┣ ╋ ┫ ┣ ┿ ┫ ┠ ╂ ┨ ┠ ┼ ┨
┉ ┋ ┗ ┻ ┛ ┗ ┷ ┛ ┗ ┻ ┛ ┗ ┷ ┛Here an excerpt. Of course, it's not _necessary_ to do it like that. It's just flavor.
┏━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━┳┅┅
┃ Chunk 1 Header │ Chunk 1 Body ┃ Chunk 2 Header │ Chunk 2 Body ┃
┗━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━┻┅┅
Chunk Header:
┌───────────┬─────────────────┐
│ Magic Nr. │ Chunk Body Size │
│ 4 Byte │ 4 Byte │
└───────────┴─────────────────┘EG the TI bq25155[1] battery charge controller PCHRGCTRL register (page 52) is divided into 3 fields. It can be quite helpful to show the layout before code to set the range.
/*
* ┌───────────────┬──────────┬─────────┐
* │ ICHARGE_RANGE │ RESERVED │ IPRECHG │
* │ 7 │ 6-5 | 4-0 |
* └───────────────┴──────────┴─────────┘
* This function sets the precharge current
* and fast-charge current step size the
* nearest 1.25mA (<= 318.75mA) or
* 2.5mA (<= 500mA).
*/
etc, etc.I now want to add table characters like these, just need to come up with a good naming convention…
[0]: https://support.apple.com/en-gb/guide/mac-help/mh35735/12.0/...
(I use a Compose key for almost all character composition, with plenty of custom mappings in my ~/.XCompose, but box drawing specifically I have skipped and use Vim digraphs, and so drop into Vim any time I want to write any.)
Also, I tend to jump a lot between editors/IDEs nowadays so I prefer workflows that don't depend on a specific tool.
There's even a Sublime Text plugin to generate this text.
Eg. https://miro.medium.com/max/1400/1*j38oOm3Pt5AMnDI3HQ6TGQ.pn...
Screenshot stolen from this Medium[0].
[0]: https://medium.com/@mumtaz.hussain/xcode-11-now-makes-mark-c...
See for example http://xahlee.info/emacs/emacs/emacs_ascii_diagram.html
Oh, also, if you want your ASCII diagrams to render into pretty pictures, I found org-mode + ditaa to work quite nicely:
https://www.orgmode.org/worg/org-contrib/babel/languages/ob-...
It isn't maintained but 90% of the features work fine. The project was picked up and is current on Atom.
Grabbing boxes for commenting is within scope of Table Editor but again, Monodraw offers some great flexibility. If you're working with code that's getting printed in a newsletter, drop it in a Monodraw box (remove border) and you can add call-outs on either or both sides of the code and paste it all in the newsletter. Looks nifty, and keeps the aesthetic consistent.
Sublime Table Editor ... https://packagecontrol.io/packages/Table%20Editor
Atom Table Editor ...... https://atom.io/packages/table-editor
Vim .................... https://github.com/dhruvasagar/vim-table-modeBeing built by @steveruizok very much worth a follow on Twitter:
Still, great idea and great implementation :)
PlantUML is readable by screen readers and contains the same information as the diagram it generates, which is the optimal balance between using visual diagrams as part of software development while not excluding the vision-impaired completely in so doing.
To be clear, I'm not scolding anyone for using ASCII diagrams, especially given that code remains stubbornly text-only. Just boosting awareness of PlantUML in terms of its accessibility advantages. I can mention meaningful diffs in version control as another advantage!
What I'd like is something like drawio for ASCII/Unicode. I've been thinking of writing my own for years, but that'll probably never happen so I'll just keep mentioning the idea when similar apps come up in the hope I inspire someone else!
I've just done a quick search and found one that I've not spotted before, which is a bit closer to what I want in that one respect, but not nearly complete overall (and not seen a check-in in 8 years): https://textik.com/ - that might illustrate the key difference that I see missing in asciiflow.
It's a shame that it's mac only.
Yeah, that looks to fit the bill nicely but is no use to me with my current mix of operating systems.
Also it would be nice to have some way of snapping boxes to a grid. Similar to creating new elements in figma. It was hard to tell when if all the boxes I made were aligned / same size.
Now I just need to find some spare time...
Tools like this helped greatly with that. Plain old text files don't lend themselves well to such 2D visual descriptions.
\o/ -huzzah
I still use Jave (http://www.jave.de/#description) occasionally, but it's beginning to show its age. It does have some nice features, though that asciiflow is missing: figlet font support and (gasp) circles!
Some other tools worth mentioning here among aficionados are PIC ( https://en.wikipedia.org/wiki/PIC_(markup_language) ) and of course cowsay. Someone already mentioned plantuml.
A simple example is markdown tables... sorting, inserting and removing columns, etc. is incredibly tedious and probably requires tools to draw, anyway.
In this line of thought, a tool like Graph::Easy sounds like a better way to come up with ascii boxes and arrows [1] (this particular tool can output other formats too).
As a plus, the underlying data can be reused for something other than docs (generating code, scaffolding directories and files, etc).
I wish I had known about this tool when I was building this little browser game https://replit.com/@aMoniker/Gush because all the levels & game objects are generated from multiline strings of ascii symbols, and it just took too long to do manually.
Maybe make a theme set - Turbopascal style, QBasic style etc
https://controlc.com/69f12f5a/fullscreen.php?hash=60268775f1...
Programming tooling really is living in the dark ages sometimes.
A screen reader can’t describe a JPEG or animated GIF. You can’t diff images/animations as easily as text. You can’t automatically translate text in images. Images and their toolchains like imagemagick introduce attack vectors. They take up more disk space. You can’t change the font of text in images. Text in images is not greppable.
Do you need to change some text in that documentation image? Hope you have the vector-based original!
And FWIW, Xcode’s rendering of markdown files and markdown doc comments with media assets in playgrounds isn’t the best experience, IMO.
Sure it can. There's a whole field of computer science for doing just that, computer vision.
>You can’t automatically translate text in images
You can use OCR to read text from images.
>Images and their toolchains like imagemagick introduce attack vectors.
This isn't fair. Text based toolchains can be vulnerable too. There have been millions of vulnerabilities with string handling
>They take up more disk space.
Buy a bigger hard drive / cloud storage.
>You can’t change the font of text in images.
Pick a readable font in the first place.
>Text in images is not greppable.
Again your could use OCR to make thi spossible.
>Do you need to change some text in that documentation image? Hope you have the vector-based original!
Check in the project file to source control or just draw over the current one.
Like, Visual Studio Code supports something like this:
https://marketplace.visualstudio.com/items?itemName=joaompin...
The Freeform tool is missing support for the brush consisting of spaces, which would make it useful as an eraser.
Every time someone utters the word "ascii", they just mean text. Saying “I'm using ASCII” doesn't mean anything anymore, because nobody uses EBCDIC anymore – you are, no matter what, effectively using a superset of ASCII, by default UTF-8. The real question is which one.
I get what you're saying, but I have seen bugs at work caused by distributed systems sending text in ASCII or UTF8 to an IBM z/OS mainframe with EBCDIC.