If you want something more featureful than Markdown, the problem isn't Markdown; it's that you're using the wrong tool for the job.
If you want something more featureful than Markdown, the problem isn't Markdown; it's that you're using the wrong tool for the job.
I find it hard to assume that Markdown is extremely well thought-through considering the fact that we didn't even get a grammar for the language, just an implementation that would be considered super broken in any other language.
Instead, Markdown should be thought of as a convention. A convention that allows for automated translation of ascii text into html. Further, instead of thinking of Markdown as designed think of it as evolved.
In the case of an evolved convention, we wouldn't expect formalism or even long term design. What we would expect and what Markdown is extremely good at is usefulness, high levels of adoption and ease of change. Which we do see. If your needs require formalism, or complex html features then Markdown is not the right tool for you.
Because markdown is for humans first and foremost, not computers. It can't be clearer than that.
If it's intended for humans first and foremost, then why offer the transpiler? After all, it already looks like ASCII e-mail. The overriding directive is human-readability, not unparsability (which do not go hand in hand).
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
http://daringfireball.net/projects/markdown/
I don't think it's far-fetched to say what tptacek did since it's dang close to what Gruber has always said about Markdown. Note that phrasing: it's not a language, it's a "plain text formatting syntax."
I don't see how the inclusion of tables violates the ascii-like readability of markdown. Github has implemented a table syntax that is natural to read/write and makes it easy to include tables in your document. Example: https://github.com/Defconbots/2015_target/blob/master/hw/boa...
|Name |Quantity|Part Number |Distributor|
|:--------------:|:------:|:------------------:|:---------:|
|BAT1, BAT2, BAT3|3 |534-082 |Mouser |
is not "natural to write"Here's an example, displayed exactly how you would see it marked up in org-mode syntax in emacs:
|-----+-------|
| Key | Value |
|-----+-------|
| 00 | foo |
| 01 | bar |
|-----+-------|
org-mode can export to HTML, and many other formats.A little known fact, even among most org-users: Github can render org-mode files to HTML directly if checked into a repo, thus you can write your README files as org-files.
Shameless example: https://github.com/josteink/csharp-mode/blob/master/README.o...
This alone was enough to make me drop Markdown as my go-to format for semi-formatted text-files.
A subtle killer feature here is org-babel. You can embed proper code in your text-files and have your editor (at least Emacs) understand them as such. Which makes it excellent for writing technical documentation for projects where code is involved.
I recently stumbled across the tidbit. The Ruby library Github uses to generate it though isn't 100% though. If you want to use org-mode properties for style customization of html output your SOL.
Original project:
https://github.com/bdewey/org-ruby
Currently, you cannot do much to customize the conversion. The
supplied textile conversion is optimized for extracting “content”
from the orgfile as opposed to “metadata.”
It does say that developement has moved to:https://github.com/wallyqs/org-ruby
Which has no such note, but doesn't say anything about supporting it.
They also support ASCIIDoc, ReST, MediaWiki markup, Creole, etc.
+ Name + Occupation
| Alice | Accountant
| Bob | Baker
| Charles | Car salesman
Headers are easier to make and the last column does not require a trailing marker. It's still some work to align columns other than the last, but that's not a requirement and I'd still much rather have a non-aligned ASCII table than nothing at all. |-----+-------|
| Key | Value |
|-----+-------|
| 00 | foo |
| 01 | bar |
|-----+-------|
becomes |-----+-------|
| Key | Value |
|-----+-------|
| 00 | foo |
| 01 | bar |
| 02 | much longer |
|-----+-------|
but as soon as I hit TAB, it turns in to: |-----+-------------|
| Key | Value |
|-----+-------------|
| 00 | foo |
| 01 | bar |
| 02 | much longer |
|-----+-------------|
There's probably a way to make org-mode dynamically resize tables as you type, without requiring the use of TAB, but I'm not sure if that's always desirable.More seriously, ASCII tables are always a major pain to edit, without the proper tools (like emacs—and I'd not be at all surprised if there's something for vim and/or Sublime Text too). That's no reason to avoid them; they are useful.