For what it's worth, I keep a file in my home folder containing some box drawing characters. It's not super fast to draw by copy-paste but the result usually looks quite nice.
Vim has digraphs for all of these characters, which I like to use. e.g. you can get ┌ with <C-K>dr (d = down, r = right), and ┨ with <C-K>Vl (V = heavy vertical, l = left). To find the mappings, :digraphs shows the whole list, or copy this block of text and put the cursor over any of the characters in normal mode and type ga and it’ll echo things like “<┠> 9504, Hex 2520, Oct 22440, Digr Vr”.
(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.)
I know, I've used them in the past. However, I get annoyed by having to remember the exact sequence for the character I want. And often, when drawing a line, I'll just copy some characters that are already there anyway.
Also, I tend to jump a lot between editors/IDEs nowadays so I prefer workflows that don't depend on a specific tool.
For those on macOS/iOS, using custom text expansions [0] also helps to do this without having to leave the doc you’re editing. I’ve built up tons of these over the years for things like ⌘ (“commandkey”) → (“rightarrow”) (╯°□°)╯︵ ┻━┻ (“tableflip”) and of course, a party parrot wave for Slack (“parrotwave” → :parrotwave1::parrotwave2::parrotwave3::parrotwave4::parrotwave5::parrotwave6::parrotwave7:). They can sync over iCloud and you can export/import them with plists.
I now want to add table characters like these, just need to come up with a good naming convention…
Biggest problem is with mobile / low horizontal resolution displays. I don't mind scrolling left and right, but in some cases the wrapping is forced (as on the HN phone app I'm using, Materialistic) and it becomes a mess. I've longed for some kind of markup system that allows for textual data to be formatted in tabular fashion irrespective of the character size of the contents, like ummmmmm HTML
It's fabulous in cases where there's a "big important business logic" or a "big important test" with tough to eliminate complexity, where you feel a diagram is so important that it's worth putting in comments beside said code. I do recommend that you be careful with this though; in places where it's not common to put ASCII art diagrams in code you'll probably receive pushback (it is afterall very large and distracting compared to said code). Be ready to save an in-code diagram for the 1-to-3 places in the business where they'll be a godsend.
It's also extremely useful for bit-mapped registers in embedded code.
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).
*/
Basically I use the same kind of philosophy as RFCs, and document things using ascii art where some kind of diagram makes sense. For example, see the TCP RFC https://datatracker.ietf.org/doc/html/rfc793 where they use it for packet layout, flow diagrams, block diagrams, etc. It makes the whole thing self contained, you can copy paste diagrams to almost anywhere, easy to modify. Disadvantage is in some more complex diagrams it can get noisy
Similar here, I use snippets for some of these things as well. As long as you're using a monospace font, I find it nice to take advantage of things like grid layouts in the extra column space for splitting up concepts into groups for example.
I usually copy from wikipedia but that's that's a good idea. In fact, since I have a "cols" command that just prints an ansi-colour table, I've just added "box" to do this.
Nice. Though it makes me think it would be nice to have this as a built in code editor minimap feature without the multi line ASCII code. The editor would parse special tags in comments and overlay the minimap with the tag text in big letters.
I think that might be derived from The "#pragma mark" feature that was in the CodeWarrior IDE which could be used to have annotations show in the drop-down list of functions in the code editor
This is a neat tool, but unfortunately, text art like this generates is extremely unfriendly to folks that use screen readers. If you do use this for comment documentation, consider making sure that there is also a written description above/below it with equivalent descriptive content.
While being an almost daily user of MonoDraw, I utilize Valery Kocubinsky's Table Editor package for Sublime at least a dozen or more times every day. All my daily habit, scheduling, trackers, and labor is in some sort of table. Thank you, Valery!
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-mode
I'm going to second this one, and add that diagrams are a real weak point for accessibility in general, one which using textual drawings exacerbates.
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!
I've seen this a few times. The key limit is that once drawn the characters are set, you can't move the drawn objects around.
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!
You can drag edges, but it doesn't seem to have a concept of a "square" beyond the tool itself. So after you've placed it, you can't move individual shapes around. The select works more like a text-editor's highlighter than something like the lasso tool in draw.io
It does, but that selects and moves the cells not the objects and then redraws the cells? Actually, going back to have a play I see that it does allow some modification of existing objects but it isn't terribly flexible.
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.
If i understand you, the Mac-only Monodraw handles this fine. It lets you draw objects, point to objects (say like a diagram), and then move them around with the pointers auto adjusting to remain correct.
It's a little tedius, but you can highlight sections and then drag the highlighted section around.
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.
A few years back I wrote a tool that would convert Ascii flow diagrams in source code comments to equivalent source code declarations that implemented the flow. The idea being that the comments didn't just describe the flow visually, but actually defined it.
Tools like this helped greatly with that. Plain old text files don't lend themselves well to such 2D visual descriptions.
It's so nice to see all this interest in ASCII art.
\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!
Wow. This is one of those "I bet someone has already done that" tools that developers wish they had but not as much to go and search for it. Bookmarked and shared. Thanks ;)
In general I feel like formats like ascii and even markdown are not great for editing. Most useful data has some sort of structure that is mostly lost when using plaintext or even MD.
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 love this and I'm going to use it for fancy comments in code and in the browser console. It'd be really cool if you could integrate something like http://www.figlet.org/ for inserting ASCII text art.
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.
I was daydreaming about something like this the other night. This is even cooler than what I was picturing! My only complaint is the download arrow threw me off for a bit, I wanted to copy to clipboard but did not realize that was hidden behind the arrow. Switching that icon to a clipboard that pops the modal might add some clarity.
It's amazing that it is 2022, and not only can we not put any kind of media in source code comments, nobody even entertains the idea that it could be possible.
Programming tooling really is living in the dark ages sometimes.
IMO text still provides the best combination of flexibility, power, simplicity and accessibility.
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.
Cool idea. I recently wanted to draw a diagram of triangles in a code comment, but unfortunately this tool doesn't seem to let you draw lines which aren't axis-aligned, so it doesn't help for that.
Why don't we all use code editors that know how to render things like Graphviz and Markdown with lists, tables? Maybe in a side window rather than in the main display, but like, come-on...
Like, Visual Studio Code supports something like this:
In the save dialog,"Extended Ascii" should probably be called "Unicode" or "Utf-8" or something. Obviously, no standard named "ASCII" provides box drawing characters and arrows.
The Freeform tool is missing support for the brush consisting of spaces, which would make it useful as an eraser.
On a general note, I think it's time to call things "text" instead of "ascii".
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.
> Saying “I'm using ASCII” doesn't mean anything anymore, because nobody uses EBCDIC anymore
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.
Ah, yes, I can see it now, but that option is almost invisible for me. I have to operate some scroll buttons at the edge to see the words "ASCII Extended".
