Hacker News Reader

Comment by dr_zoidberg | Hacker News Reader

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.

View on HN

Try removing one of the left boxes (not exactly easy in this format) and then view the git diff. Think about trying to fix a conflict with that!

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.

Now you then need to cut and paste back and forth from your documents in order to edit them.

Not if you import that format as well, that's not impossible to implement.

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.

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.

This. I would love, as an author and teacher, to keep my flowcharts, diagrams, etc with my book code.

Right now I'm using SVG for that, but it's kinda rotten.

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.

Does that solve your problem?

[0] https://www.draw.io/?splash=0

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.

I use draw.io, and export to xml.

It should be easy to do flowcharts in pic(1). It's also more diff-friendly.

GNU pic can target LaTeX directly, if that helps.

Agreed. This could be very useful if leveraged into a Wiki-plugin.

It is also supported in your text editor.

SVG/GraphML are text based too

SVG cannot be entered by humans in the same way this can

I don't agree. SVG is very human-editable indeed. It's easier than even PostScript or OpenGL.

To each his own then I guess. Some may enjoy aligning pipe symbols and pluses, I don't.

I don't either, but I enjoy cutting and pasting back and forth, or keeping diagrams in separate formats, or trying to write SVG manually even less.

Reply on news.ycombinator.com