I think the appeal would be that, since it's text based, it's already supported by git/mercurial/svn/name-your-vcs. A binary format would need some sort of history/diff support inside it to work well with a specific plugin for s VCS. An XML-based format would integrate well with a VCS, but you lose the clarity of the ASCII based diagrams.
It may seem "cute" or "toyish", but I woudl try to use it before giving an opinion. I certainly did that with markdown and ended up moving a lot of docs to that format, right in the repos with the code.
Indeed, side-by-side boxes editing/merging would be messy! But it still looks that something that could be integrated into a reasonably organized repository. Not the best of tools, but better than the alternative?
"since it's text based, it's already supported by git/mercurial/svn/name-your-vcs"
But doesn't that still apply if you had a visual tool exporting to ASCII? It'd save you the difficulty of moving sections around in a text editor, but give you the visual diff.
No, "supported by git" means that if I edit the diagram and check it in, and you also edit the diagram and check it in, Git can usually merge the changes automatically if they don't conflict; and if they do conflict, it can give us a version of the file that contains both changes, with the conflict marked, and makes it pretty easy to produce a merged version.
If your visual tool merely exports to ASCII, this won't work. If it stores its data in ASCII, it might. But it needs to be more than just "doesn't use control characters and non-7-bit characters" — it needs to have reasonably short lines that mostly don't reoccur and whose position, if meaningful at all, is meaningful only relative to the position of other nearby things, rather than by absolute line number or byte position or something.
If you come up with a tool that will pick up on a diagram in a readable ascii format in the middle of a document, let me edit it, and then patch in the updated diagram without making any kind of changes to other portions of the file, then we'd be getting somewhere.
Even then there'd be issues, as e.g. I might want to modify descriptions elsewhere in the file in between modifying the diagram. As a concrete example, I am doing that these days with a spec for a system I'm planning. I'm using a custom Markdown based processor with a filter that takes Graphviz/dot syntax inline, and while I edit the diagram, I'll also then often want to write something about what I've added to it. So if I was going to use an external program, the roundtrip from text editor -> diagram editor -> text editor would need to be very fast and smooth.
Though to be really useful for me, it'd need to work for me via an ssh connection as well...
It's really hard to beat plain text for some of these use-cases. At least without first getting more graphics capabilities back into our terminals.
Is that same problem, i.e. you want to be able to diff your diagrams or do you want the actual data format embedded in your document.
If it's the second, you can embed XML within SVG or a PNG. If you draw something simple in draw.io [0] (which I do co-author) and then "File->Export As" either "SVG with XML" or "PNG with XML" the diagram data is stored within the display format itself. This way you can just reload the SVG+XML or PNG+XML and carry on editing. But the PNG and SVG display as you'd normally expect.
Yeah, I feel this pain too. MJD's Linogram might work. I've also tried writing the diagrams as Python to produce SVG, or in D3 (to produce SVG), which both work reasonably well but seem like a lot of work.
It may seem "cute" or "toyish", but I woudl try to use it before giving an opinion. I certainly did that with markdown and ended up moving a lot of docs to that format, right in the repos with the code.