3 ms·
> last update: 2020-12-14 Exactly what we needed, another format! I agree with the general sentiment, that long-term documents should be human readable. But e
by bArray 6y ago
> last update: 2020-12-14
Exactly what we needed, another format!
I agree with the general sentiment, that long-term documents should be human readable. But essentially what is being designed here is just a text document with very specific formatting, that isn't even really designed to be parsed that well.
What sucks about the format proposed is that it's not going to be so easily parsed by a human/machine. I would instantly do away with the concept on index data, the hashing technique is really not going to provide any real advantage. I think this is the sort of thing that should be left to the implementer to decide when parsing the documents, rather than per-specified.
Honestly, in terms of portability, I would prefer to pick a subset of markdown. Perhaps you could apply the following restrictions:
1. Headers to use '#' and not underline feature.
2. Stick to a line wrap of 80 characters (or less if older machines require it).
3. Code blocks should use fours space indentation and not back-ticks ('```').
4. Table should be correctly white-spaced to make the formatting nice and human viewable.
5. Do away with embedded images and instead use links.
6. 7-bit readable ASCII only, no tabs (as they suggest). A tab is different on each machine (and it bugs the living hell out of me in codebases too).
7. A twist on the idea specified, "links" (to files/documents) should be unique for the first 12 characters (or an appropriate specification). This would allow them to be longer and more verbose, but also backwards compatible.
One thing I think markdown compromises on and maybe it shouldn't have is links. I think the format:
[link_text](link_location)
Should have been something like:
[link_location]
Where the location is simply displayed. I feel like the idea of hiding the content of a link is deceptive - it's name should really reflect what is actually is and by displaying the link itself you encourage it to be as short as possible.
Anyway, that's my 2 cents.
- flobosg 6y ago> Should have been something like: [link_location] Markdown has a similar syntax using angle brackets, i.e., <link_location>. See https://daringfireball.net/projects/markdown/syntax#autolink https://daringfireball.net/projects/markdown/syntax#autolink.
- bArray 6y agoWoah, I was never aware of this, thanks!
- PaulHoule 6y agoThe advantage of that AMB format is that it does not depend on large and variable-length data structures so you can easily implement a viewer in BASIC or macro assembler on an "8-bit" computer like the Apple ][. (e.g. a friend of mine wrote a "filesystem" in BASIC on a TRS-80 Color Computer that stored 90kb on a floppy side (you flip) and also built a "robot" that could change floppies. The IBM PC was double density and heads on both sides so it stored 4 times as much, 360kb on a floppy, the early C64 split the difference around 150kb,...) I think the hash index is cute and probably scales up to the 1.2MB floppy range that came with the PC AT.
- goldsteinq 6y agoCode blocks should use backticks (which allow to specify a language and easy to type).
- livre 6y agoThey aren't easy to type in all keyboard layouts, in my Spanish keyboard you have to press alt gr+backtick twice (because it's a dead key), that's 3 key presses for a single backtick, you need 14* in total if you are using 3 backticks at the beginning and 3 at the end. Some people have even bigger issues like more keys to press or no backtick at all[1] Backticks are such an annoyance for me that when I started learning programming I dreaded having to type them and actively avoided languages that relied too much on them. * 7 per each 3 consecutive backticks if you don't accidentally release the alt gr [1] https://spaghettidba.com/2011/09/19/typing-the-backtick-key-on-non-us-keyboards/ https://spaghettidba.com/2011/09/19/typing-the-backtick-key-...