Enhancement: Github Flavoured Markdown

[jamesray1]

System information

AKASHA version: 0.6.1

Operating System: Ubuntu 17.10

Steps to reproduce the problem

Enter this in a draft and publish it:

---

It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)
Sometimes you want numbered lists:

1. One
2. Two
3. Three

Sometimes you want bullet points:

* Start a line with a star
* Profit!

Alternatively,

- Dashes work just as well
- And if you have sub points, put two spaces before the dash or star:
  - Like this
  - And this
If you want to embed images, this is how you do it:

![Image of Yaktocat](https://octodex.github.com/images/yaktocat.png)
# Structured documents

Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.

### This is a third-tier heading

You can use one `#` all the way up to `######` six for different heading sizes.

If you'd like to quote someone, use the > character before the line:

> Coffee. The finest organic suspension ever devised... I beat the Borg with it.
> - Captain Janeway

There are many different ways to style code with GitHub's markdown. If you have inline code blocks, wrap them in backticks: `var example = true`.  If you've got a longer block of code, you can indent with four spaces:

    if (isAwesome){
      return true
    }

GitHub also supports something called code fencing, which allows for multiple lines without indentation:

if (isAwesome){
  return true
}

And if you'd like to use syntax highlighting, include the language:

```javascript
if (isAwesome){
  return true
}

GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!

But I have to admit, tasks lists are my favorite:

- [x] This is a complete item
- [ ] This is an incomplete item

When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!

And, of course emoji! :sparkles: :camel: :boom:

Source: https://guides.github.com/features/mastering-markdown/

---

[RMBLRX]

I generally agree but would also add that another flavor of markdown might be preferable due to GFM's lack of (easy) support for footnotes; however, there's always HTML to fill in the gaps. Personally, I would like to have an editor-agnostic way of interfacing with Akasha (a CLI, perhaps); and yeah, GFM/CommonMark and its support for HTML would probably be the most standardized way to accomplish this, though, going forward, supporting a more extensive Markup, like Markua might be preferable. Markua should, I believe, be perfectly backwards compatible with GFM (i.e., allowing simple GFM to be used in lieu of anything Markua-specific, due to its basis in CommonMark).

On a side-note, Markua supports CriticMarkup, which could be a boon for allowing readers to help revise and comment on the content of a post in human-readable way that can be written directly to IPFS; as in, commenting on the text body (or perhaps even commenting in general) would amount to forking that post with whatever suggested edit and/or comment they contribute.

[jamesray1]

@RMBLRX, sounds reasonable, although I haven't used those that you mentioned, except for GFM and HTML.

[RMBLRX]

It's still in development, but it seems like it's going to have the most complete feature sets (much of it borrowed from Pandoc, I guess), implemented without invalidating vanilla Markdown or, likely enough, GFM/CommonMark. It could be overkill for blogging, or it could be the ticket for ensuring that users can make the most of the platform: If a markup is feature-complete for publishing books, I should think it would more than suffice for blogging.

One area that may be lacking in Markua for blogging is frontmatter (for metadata). I would think something like Gray-matter, which seems just about identical to Jekyll's frontmatter, would suffice.

Really, I just want to one day interface with Akasha from within Emacs and wish to ensure that's as painless as possible. The main editing interface wouldn't even have to reflect all of this explicitly, just so long as we have a route to edit in this fashion and have it format correctly when previewed and posted.