That said, I'm OK with it degrading like that. The text file is perfectly readable, and conveys the information within quite well. I even kind of preferred it.
So, yeah. Great job, OP.
Oh don't worry. They'll let you know. Any chance they get.
And don't tell me you actually like default browser scrolling, my custom JS scrolling is much better.
Oh and don't worry about the load time, that only happens the first time, after that the 30Mb of content is cached so its fine.
I opened the site, saw two identical boxes of text with some ascii in the middle, read the first paragraphs.. then scrolled down and saw some license thrown in there...
Almost got too happy seeing a satire get so popular on HN. :(
I'm over Markdown and related formats for the web. We have a great ASCII format for marking up the web, and it's called HTML.
1. My text editor (Vim in this case) renders the text file in colors, and helps me distinguish different elements.
2. If I want, I can export to html.
Markdown and the like grew out of what people were already doing in plain text: dashes and asterisks for bullets, indentation, etc.
I would much rather write plain text, or minimally marked up Markdown or rst, than have to write <tags> for everything, especially for something like my text file that isn't really intended for the web, but can be converted if needed. html is not really meant to be read, but rendered. The various markdowns can be comfortably written, and read as is.
There is not need to learn another version of Markdown, the diagrams are just plain ASCII and Markdeep supports the Markdown you know and love, plus more.
I think it is great, I love it!
(And frankly, the diff thing is nonsense, too. Diff produces an unreadable mess on ASCII art. I'd rather see the diff of some XML that shows me nodes added, removed, properties changed.)
You need a better editor, that's all. Emacs has picture-mode and artist-mode; no doubt vim has something too, although a quick search didn't help.
There is lots of prior art extracting diagrams from textual drawing but AFAIK all required global conformance to some accepted "syntax". Markdeep's(?) idea of local beautification while maintaining the global fixed-width layout is brilliant as you're not limited to particular structures and anything unsupported degrades gracefully!
(If this idea has no name, let's call it "2D ligatures"?)
We could have a dozen different tools based on this idea, each supporting a somewhat different dialect, yet any diagram will be reasonably readable under any of them — which is exactly the quality you want when excavating a 40-year-old README of unknown origin.
It's the simplest thing that could possibly work. Except one: using line drawing characters directly in the source (and requiring no tool at all, just view in fixed-width font). Let's try:
* . *
* 0 3 P ● Eye ╱ ▶ ╱ *
* ●───────● +y ╲ 〈) ╲ ╱ Reflection *
* 1 ╱│ 2 ╱│ ▲ ╲ ╲ ╲ ▶ *
* ●───────● │ │ v0 ╲ v3 ────────●──────── *
* │ │4 │ │7 │ ●────╲─────● *
* │ ●─────│─● +─────▶ +x ╱ ◀ X ╲ ◜⎺◝◀──────── ○ *
* │╱ │╱ ╱ ╱ ○ ╲ ( ╱ ) Refraction ╱ ╲ *
* ●───────● ▶ ╱ ╲ ◟⎽◞ ╱ ╲ *
* 5 6 +z v1 ●──────────────────● v2 │ ○─────○ *
* ▼ *
2. Version control for binaries sucks.
3. Graphical tools can be very awkward when aligning stuff. MS Word, for example, is a pain for making diagrams in.
There are literally dozens of examples of text-based markup tools that are cross-platform, version-controllable, and can be rendered in a terminal if you're into that, and which don't require me to waste time drawing ridiculous ASCII art borders to denote logical relations.
Now if all editors could come up with a compatible ascii graphic drawing tool that would actually be useable.
So for ascii diagrams, you might have an external program that generates, at least, various kinds of boxes and connectors, then you could edit the labels from the editor. Bonus if the external ascii diagram generator would take labels associated with entities.
Maybe that's an additional feature for Markdeep, or maybe it's a specific itch for someone else to scratch.
some years ago i rendered .rst urls using a cgi shell script that drove rst2html.py from docutils.
On the other hand, that ASCII-art-to-SVG conversion is golden, and I'd absolutely love to have that supported in my API docs and blog-posts.
I for one love that it doesn't require a preprocessing step, because it means that any text file can easily be rendered without any need to do anything else.
Fantastic job OP, I think this is really awesome. Would be perfect if this was integrated with github - I would do all my readmes with this.
Speaking as a PL & s-exp guy, I don't really have a problem writing
(item "pick up milk")
(item "drop off desk"))
... but at the end of the day, I see that I can convey the same structure in a clearer way using markdown. Markdown is lovely because it's the thinnest possible skin over the structure; you can immediately see what structure the syntax is attaching. (Yes, there's still some parsing nastiness around paragraphs). This thing, though, doesn't have that "brilliant solution to a simple but really important problem" feel to it. I don't see this catching on.
Of course, I said the same thing about the internet in the spring of 1993.
If you want to use an underline for emphasis instead of cursive, this is more of a style concern than anything else, so the appropriate place to change this would be in the stylesheet, which is perfectly possible.
If you specifically want it to output the <u> html tag, I agree that this is not as convenient.
I'm going to have to disagree with you. Long before Markdown came along, the convention was to use asterisks for * bold *, slashes for /italics/ and underscores for _underlined_ text. And that's just for starters.
Those three examples perfectly convey the intended effect, quite unlike the Markdown versions where asterisks will somehow imply italics, but only if they're single asterisks? It's a strange thing!
Historically underlined content == actionable hyperlink; for content that is intended for public consumption (ie. not a note that you're writing for your own use) there are usability issues with typographic styles that represent emphasis with an underline.
But I like the more WYSIWYG approach (if I dare say) of Markdeep.
Markdeep is open source. You may use, extend, and redistribute Markdeep without charge under the terms of the BSD license:
Markdeep includes markdown.js, so you are also bound by the MIT license (which is BSD-compatible):
...and the highlight.js BSD license:
If I understand correctly that means I have to serve all three licenses in my HTML?
(disclaimer: I didn't check)
I think before there were GUI tools for editing ladder diagrams , there were tools that would read ASCII-art diagrams, and program PLCs with the corresponding logic. However, a quick Google didn't give a source confirming this.
Screen cast showing it off: http://www.cinsk.org/emacs/emacs-artist.html
> The current 0.01 beta release is minified-only to find bugs and get feedback, but a full source version is coming soon after some more code cleanup.
Can I call this on a string using a function, returning an html string, rather do it for the whole page?