> I wish there was some reasonable standard (like a better version of Rich Text) that was commonly adopted so other languages could put graphical pictures in the source code.
I have felt exactly the same for many years. It would need to be something that was totally open (to achieve wide adoption), and reasonably easy to support in IDE's for edit and preview. And git-friendly. Belly-flopping on an existing standard is probably the easiest way to make that happen.
One thought is to presume a block comment with a language-specific marker, and make the contents a restricted subset of Postscript. a) You get one or two open-source fonts. Deal with it. b) The rendering area is strictly limited, c) the operator subset is limited to something reasonable -- like just enough to do a monochrome version of 80% of the kind of graphics that PowerPoint-ish programs give you.
Of course, you would never want to write Postscript by hand (although it isn't hard) but an IDE should be able to support a graphical editor plug-in. Or in a pinch you could even use another tool that left the rest of the code alone, and just edited the graphical block comments.
There's a Visual Studio plugin that I use that does this. I have an images directory in my source tree and in comments I can refer to them with syntax that looks something like:
/* <img source="images/bubble_sort.png"/> */
If you have the plugin installed, the image is displayed immediately after that line.
Developed in 1982. Present on almost every UNIX-like system and integrated into the manpage generator.
Probably the main reason we've not seen things like this achieve wide adoption is the small but very influential subset of programmers who refuse to use anything that isn't a pure text terminal for development.
Interesting. I'm not familiar with "pic", but I'll check it out. I've never seen a manpage with that in it.
A terminal with graphics in it would be nice too. Maybe if Tek4014 (and the Tek emulation in xterm) had graphics and useful text simultaneously it would've been more popular than the modal approach. I've also heard of Sixel, but never seen it live.
How about 3 fonts (serif, sans, and fixed) and color instead of monochrome? You're too quick to compromise :-)
Vector graphics would be adequate and could discourage huge binary dumps in the code, but you know someone would try to jam a photograph in there by inserting a square per pixel, and I can't really blame them. Postscript could work, but if you picked something explicitly line oriented it would cause less confusion in revision control.
> How about 3 fonts (serif, sans, and fixed) and color instead of monochrome? You're too quick to compromise :-)
Minimal Viable Picture :)
> Postscript could work, but if you picked something explicitly line oriented it would cause less confusion in revision control.
Agreed. But Postscript has a lot of existing unencumbered infrastructure code littering the net. With a new syntax, you need to overcome an activation energy problem. You would have to make sure that rendering and editing code existed that could be munged into a plug-in for everybody's favorite IDE. EMACS mode, anyone?
Also, maybe an independent tool that ran in a local web browser (not uploading code to random servers) would be a way to jump start things.
I have felt exactly the same for many years. It would need to be something that was totally open (to achieve wide adoption), and reasonably easy to support in IDE's for edit and preview. And git-friendly. Belly-flopping on an existing standard is probably the easiest way to make that happen.
One thought is to presume a block comment with a language-specific marker, and make the contents a restricted subset of Postscript. a) You get one or two open-source fonts. Deal with it. b) The rendering area is strictly limited, c) the operator subset is limited to something reasonable -- like just enough to do a monochrome version of 80% of the kind of graphics that PowerPoint-ish programs give you.
Of course, you would never want to write Postscript by hand (although it isn't hard) but an IDE should be able to support a graphical editor plug-in. Or in a pinch you could even use another tool that left the rest of the code alone, and just edited the graphical block comments.