burodepeper / language-markdown

Add support for Markdown to Atom (including Github flavored, Markdown Extra, CriticMark, YAML/TOML front-matter, and R Markdown), and smart behavior to lists.

Markdown grammar

A realistic implementation of various Markdown specifications as a flexible, drop-in alternative for language-gfm. Adds smart context-aware behavior to lists, and keyboard shortcuts for inline emphasis and links/images.

Note
This package is no longer actively maintained.
Since the development of Atom seems to have slowed down, I've stopped using Atom as my primary editor, and consequently, this package. If you are interested in taking over maintenance, you can contact me via my Github profile. I intend to respond to new issues as best as I can.

Installation

1. Install language-markdown via either

• your terminal: apm install language-markdown
• the Atom GUI: Atom > Settings > Install > Search for language-markdown

2. Select language-markdown as your Markdown grammar. Open a Markdown file and

• press ctrl+shift+L and choose "Markdown"
• choose "Markdown" from the grammar selection interface in the bottom right-hand corner of the window

To avoid conflicts this package tries to disable the core package language-gfm. If you run into any issue, make sure you've selected the correct grammar.

Supported grammars

• CommonMark Markdown
• Github Flavored Markdown (including AtomDoc)
• Markdown Extra
• CriticMark annotation
• Front Matter (yaml, toml and json)
• R Markdown

Additional features

• Smarter lists
  • Automatically create new list-items when pressing enter
  • Indent or outdent list-items by pressing tab or shift+tab
  • Toggle tasks with cmd+shift+x or ctrl+shift+x
  • Remove empty trailing list-items when pressing enter
• Add shortcuts (via _, * and ~) for toggling inline-emphasis and strike-through on selected text
• Add shortcuts for converting selected text to a link (via @) or an image (via !)
• Supports embedded HTML- and Liquid-tags
• Embedded math functions (via language-latex and language-mathematica)

Syntax-theme support

By default, most syntax-themes only provide basic styling for .markup classes. This package provides additional, more specific classes which are supported by the following syntax-themes:

• minimal-syntax (light, high-contrast)
• minimal-syntax-dark (dark, high-contrast)
• pen-paper-coffee (light, low-contrast)
• pubster-syntax (dark, high-contrast)
• one-o-eight-syntax (various, medium-contrast)
• east-end-syntax (light, medium-contrast)
• east-end-notebook-syntax (light/lined, medium-contrast)

If you are interested in adding support for all .markup classes to your syntax-theme, take a look at the relevant section in the contribution guide.

F.A.Q.

If you run into any issues, consult the F.A.Q. first. Amongst other things, this document contains information about common issues involving:

• spell-check
• autocompletion
• syntax-highlighting
• whitespace

Contributing

If you want to contribute to this package, have a look at the contribution guide.

language-markdown's Issues

Create a separate token for the 'checkbox' in task-lists

after install markdown preview not working

hi,

after install language-markdown the markdown preview doesn't work.
disable package doesn't solve
deinstallation package solve the problem

Installation fails

This package is failing to install for me on:
Atom 1.0.19
Windows 8.1 x64

Installing “[email protected]” failed.

> [email protected] install C:\Users\Landon\AppData\Local\Temp\apm-install-dir-115921-231128-1opv8ga\node_modules\language-markdown\node_modules\pathwatcher\node_modules\runas
> node-gyp rebuild


C:\Users\Landon\AppData\Local\Temp\apm-install-dir-115921-231128-1opv8ga\node_modules\language-markdown\node_modules\pathwatcher\node_modules\runas>if not defined npm_config_node_gyp (node "C:\Users\Landon\AppData\Local\atom\app-1.0.19\resources\app\apm\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node  rebuild ) 
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
MSBUILD : error MSB4132: The tools version "2.0" is unrecognized. Available tools versions are "4.0".

gypnpm ERR! Windows_NT 6.2.9200
npm ERR! argv "C:\\Users\\Landon\\AppData\\Local\\atom\\app-1.0.19\\resources\\app\\apm\\bin\\node.exe" "C:\\Users\\Landon\\AppData\\Local\\atom\\app-1.0.19\\resources\\app\\apm\\node_modules\\npm\\bin\\npm-cli.js" "--globalconfig" "C:\\Users\\Landon\\.atom\\.apm\\.apmrc" "--userconfig" "C:\\Users\\Landon\\.atom\\.apmrc" "install" "C:\\Users\\Landon\\AppData\\Local\\Temp\\d-115921-231128-m1k57s\\package.tgz" "--target=0.30.7" "--arch=ia32"
npm ERR! node v0.10.40
npm ERR! npm  v2.13.3
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the runas package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls runas
npm ERR! There is likely additional logging output above.

From a bit of searching it almost looks like I would need to install VS2013 (or higher)? chjj/pty.js#60

As this hasn't been required for any other Atom package that seems a bit odd...
If you need any more information please let me know.

Add spec for gfm task-lists

Nested square-brackets in references are not properly detected

If a [ ] pair is used, but not part of a reference, it get's scope assigned incorrectly.

The first is scoped: <span class="punctuation md">[</span> while the second is un-scoped.

CriticMarkup

I can take the lead on this. It's actually simple, here is the code I contributed to language-gfm:

{
    'begin': '{\\+\\+'
    'end': '\\+\\+}'
    'name': 'critic.gfm.addition'
    'captures':
      '0':
        'name': 'critic.gfm.addition.marker'
  }
  {
    'begin': '{--'
    'end': '--}'
    'name': 'critic.gfm.deletion'
    'captures':
      '0':
        'name': 'critic.gfm.deletion.marker'
  }
  {
    'begin': '{=='
    'end': '==}'
    'name': 'critic.gfm.highlight'
    'captures':
      '0':
        'name': 'critic.gfm.highlight.marker'
  }
  {
    'begin': '{>>'
    'end': '<<}'
    'name': 'critic.gfm.comment'
    'captures':
      '0':
        'name': 'critic.gfm.comment.marker'
  }
  {
    'begin': '{~~'
    'end': '~~}'
    'name': 'critic.gfm.substitution'
    'captures':
      '0':
        'name': 'critic.gfm.substitution.marker'
    'patterns': [
      {
        'match': '~>'
        'name': 'critic.gfm.substitution.operator'
      }
    ]
  }

It would probably be better if it also handled the optional user mentions. I can work on a PR.

Improve syntax-highlighting compatibility with default syntax-themes

Hi,

I love this package as it is handy when I am writing posts on my GitHub pages website, but I have noticed that syntax highlighting goes haywire when <a href="..." target="_blank"></a> (HTML tag for creating hyperlinks that open in new windows) is included in a markdown document. See this screenshot, for example:

While I realize this error is due to HTML and not markdown, the language that this package is meant to support, I was wondering if I might request this support be added as a feature request.

Thanks for your time,
Brenton

Alternative to indented code blocks

According to the CommonMark specs, any text indented four or more spaces is considered an indented code block, unless it is part of a nested list-item, but that is not something we're able to detect. To not cause any unwanted highlighting of nested quotes and/or lists, indented-code blocks are disabled by default. And since fenced-code-blocks provide an excellent alternative, I think this is a good decision.

What rests is the question how to interpret lines that are indented four or more spaces. The specs allow for list-items to be indented any number of spaces, but for instance for headings and quotes, it allows a maximum of three spaces (because of indented code). Should this limit of three spaces be abandoned?

For example (first is 3, 3, 1 spaces, second is 4, 4, 4 spaces):

   > # Foo
   > bar
 > baz

vs

    > # Foo
    > bar
    > baz

The markdown preview in this issue chooses to ignore the three character limit apparently, but at the same time, it doesn't recognize the header inside the quote.

I think my vote leans towards dropping the three character limit.

Improperly scoped `&`

In the screenshot below, the & in Black & White is being scoped as <span class="invalid illegal bad-ampersand html">&amp;</span> and should not be.

Remove (trailing) empty list-item after pressing enter

When pressing enter within the scope of a list, a new list-item is created, unless the list-item is empty. I believe it is safe to assume that a trailing automatically added list-item is a remnant, and can be safely replaced by an empty line.

@user versus @citationkey

Here is a suggestion. In gfm, @user mentions a user. In pfm, @citationkey cites an item in the bibliography.

Ideally, the package would be able to separate the two, as a function of the markdown flavor being used.

html doesn't work in list items

italics and bold in same line fails

This is not the expected behavior:

Order of rules when combining new Grammar

Hey @leipert,

While working on the emphasis rules, I've noticed that emphasis is matched before links are, though I specifically specify that links come before emphasis in /rules/main.cson. Could you confirm if the order specified is actually preserved when the composited grammar is created?

Tables

Here is the relevant code I contributed to language-gfm

What is missing is that it currently does not parse markdown within the tables (so italics are not rendered as italics).

{
    'begin': '^\\|'
    'end': '(\\|)?\\s*$'
    'beginCaptures':
      '0':
        'name': 'border.pipe.outer'
    'endCaptures':
      '1':
        'name': 'border.pipe.outer'
    'name': 'table.gfm'
    'patterns': [
      {
        'match': '(:?)(-+)(:?)'
        'captures':
          '1':
            'name': 'border.alignment'
          '2':
            'name': 'border.header'
          '3':
            'name': 'border.alignment'
      }
      {
        'match': '\\|'
        'name': 'border.pipe.inner'
      }
    ]
  }

Detect empty task item

A list-item with a not completed task - [ ] is rendered as a list-item with an empty link-label.

Mark hyperlink incorrect when the link contains underscore

Add extended dashes to punctuation part of comment

Add keybinding to toggle list-item between ordered and unordered

Failed to load the language-markdown package

[Enter steps to reproduce below:]

1. ...
2. ...

Atom Version: 1.3.1
System: Mac OS X 10.10.5
Thrown From: language-markdown package, v0.7.0

Stack Trace

Failed to load the language-markdown package

At Cannot find module 'season'

Error: Cannot find module 'season'
    at Module._resolveFilename (module.js:336:15)
    at Function.Module._resolveFilename (/Applications/Atom.app/Contents/Resources/app.asar/src/module-cache.js:383:52)
    at Function.Module._load (module.js:286:25)
    at Module.require (module.js:365:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:41:21)
    at Object.<anonymous> (/Users/haiker/.atom/packages/language-markdown/lib/main.coffee:2:8)
    at Object.<anonymous> (/Users/haiker/.atom/packages/language-markdown/lib/main.coffee:1:1)
    at Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:92:30)
    at Object.defineProperty.value [as .coffee] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:41:21)
    at Package.module.exports.Package.requireMainModule (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:663:34)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/package.js:115:28
    at Package.module.exports.Package.measure (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:92:15)
    at Package.module.exports.Package.load (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:106:12)
    at PackageManager.module.exports.PackageManager.loadPackage (/Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:438:14)
    at PackageManager.module.exports.PackageManager.loadPackages (/Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:390:14)
    at AtomEnvironment.module.exports.AtomEnvironment.startEditorWindow (/Applications/Atom.app/Contents/Resources/app.asar/src/atom-environment.js:682:21)
    at module.exports (/Applications/Atom.app/Contents/Resources/app.asar/src/initialize-application-window.js:28:10)
    at setupWindow (file:///Applications/Atom.app/Contents/Resources/app.asar/static/index.js:85:5)
    at window.onload (file:///Applications/Atom.app/Contents/Resources/app.asar/static/index.js:40:9)

Commands

Config

{
  "core": {
    "themes": [
      "atom-dark-ui",
      "atom-dark-syntax"
    ],
    "projectHome": "/Users/haiker/",
    "openEmptyEditorOnStart": false
  }
}

Installed Packages

# User
language-gradle, v0.0.3
language-markdown, v0.7.0
language-sql, v0.20.0

# Dev
No dev packages

Add Markdown Extra flavor

See: https://michelf.ca/projects/php-markdown/extra/ and atom/language-gfm#56

• Add special attributes ({#id .class key=value}) to:
  • Headings
  • Fenced code blocks
  • Links
  • Images
• Definition lists
• Footnotes
• Abbreviations

Add AtomDoc references

As mentioned in https://github.com/atom/atom/blob/master/CONTRIBUTING.md#documentation-styleguide

Pipe symbol subscript in Markdown syntax highlighting wrong

Writing a pipe symbol followed by an underscore, |_ (for subscript in math-mode) makes the syntax highlighter think any text after is emphasised. The highlighting can be escaped using two underscores, but I don't think this should happen in the first place (unless there is some reason I am not aware of yet).

Yaml syntax highlighting

First of all I commend you for taking the time to write and maintain this package & am very grateful for the effort.

Now, the issue: before updating to v. 0.0.12, I had no YAML syntax highlighting whatsoever. After the update, I have this:

For comparison, under GMF, I have this:

I'm running Atom 1.0.19 on Ubuntu 15.04

Installation fails on Windows; fails at the [email protected] install script 'node-gyp rebuild'

"Installing “[email protected]” failed."
Windows 7 x64;
Atom 1.0.19;

> [email protected] install C:\Users\VolodyaM\AppData\Local\Temp\apm-install-dir-115925-6268-bhmv2e\node_modules\language-markdown\node_modules\pathwatcher\node_modules\runas
> node-gyp rebuild


C:\Users\VolodyaM\AppData\Local\Temp\apm-install-dir-115925-6268-bhmv2e\node_modules\language-markdown\node_modules\pathwatcher\node_modules\runas>if not defined npm_config_node_gyp (node "C:\Users\VolodyaM\AppData\Local\atom\app-1.0.19\resources\app\apm\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node  rebuild ) 

gypnpm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Users\\VolodyaM\\AppData\\Local\\atom\\app-1.0.19\\resources\\app\\apm\\bin\\node.exe" "C:\\Users\\VolodyaM\\AppData\\Local\\atom\\app-1.0.19\\resources\\app\\apm\\node_modules\\npm\\bin\\npm-cli.js" "--globalconfig" "C:\\Users\\VolodyaM\\.atom\\.apm\\.apmrc" "--userconfig" "C:\\Users\\VolodyaM\\.atom\\.apmrc" "install" "C:\\Users\\VolodyaM\\AppData\\Local\\Temp\\d-115925-6268-h5olv8\\package.tgz" "--target=0.30.7" "--arch=ia32" "--msvs_version=2013"
npm ERR! node v0.10.40
npm ERR! npm  v2.13.3
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the runas package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls runas
npm ERR! There is likely additional logging output above.

Main discussion about the aim of this package

See [README.emdee]

Separate gfm-block from gfm-inline elements

Add support of mermaid diagrams like https://cloose.github.io/CuteMarkEd/ has

Add support of mermaid (https://knsv.github.io/mermaid/) diagrams like https://cloose.github.io/CuteMarkEd/ has.
E.g. you write in md

   ```mermaid
     graph TD;
          A-->B;
          A-->C;
          B-->D;
          C-->D;
    ```

Preview (in fact mermaid) renders diagram.

Fenced codeblocks

There are a number of issues with fenced code blocks (in existing packages).

1. Language detection. For exemple, if I write ~~~ langname, unless there is a rule that imports language-langname, there is no highlighting. Solving this would be awesome, but I'm not sure how.
2. Different syntaxes for blocks. For example, the simplest is gfm, which uses ~~~ langname. But many other (pandoc, notably, as well as packages like knitr, Judo, ...), use ~~~{.langname key=value key=value}. Ideally these would be detected, and parsed.

I can try my hand at some of these, but I have the feeling that solving point 1 would allow to work on point 2 in a more general way. Ideas?

The big question about emphasis: multiline or not?

I have been working on the rules for emphasis today and I finally understand why it is such an issue. I have been breaking my head (a little) over why the multiline tag (?m:subexp) in regexp doesn't work. I haven't found definite proof, but because TextMate parsed things line by line, Atom apparently does as well. As I see it, this puts us in an either/or situation.

Option 1: multiline

Multiple lines are kind of possible when using nested patterns and thus the following type of pattern matching:

begin: $pattern
end: $pattern

By far the biggest issue with this option is that the end pattern is optional. That means that when the begin part is matched, the scope will be open until and only when it is closed. That's the cause of that single * or _ somewhere that sets all your text in italics. I've personally had completely realistic uncomplicated situations where this caused Atom to be unusable for that particular document.

Option 2: no multiline

Because I hoped I could rely on (?m:subexp) I have already started to work into that direction. But because that flag doesn't work, this turns my rules in to single lines. A big bonus is that that automatically fixes a lot of edge cases with weirdly nested types of emphasis, but it also doesn't allow for displaying multiline inlines in Atom.

---

To start of honestly, I am already biased against multiline inlines.
My point of view is that emphasis is something that applies to most likely a few words, and that I see nested emphasis as a realistic possibility, but one that should be avoided and to 'just' write a better text. When you want to emphasize something that spans multiple paragraphs (ie, a single paragraph is technically a single line) then I think those paragraphs shouldn't be split up in the first place.

In an attempt to be unbiased, I will try to sum up some practical stuff.

• A syntax highlighter's purpose is to give semantic meaning to a text by augmenting it with scopes.
• The definitive styling of a document is defined by a stylesheet, and perhaps prematurely interpreted by a preview-package.
• The syntax highlighter itself does not even add styling, that's what a syntax theme does. But that also means that we can't rely on that syntax theme.
• By definition, I think a syntax highlighter should be more reluctant, rather than eager to do something. It shouldn't try to decide things for a user.

I think that from these could be concluded that option 1 could be considered invasive to a user, and that therefor option 2 would be slightly better as a default setting, because...

Option 3: let the user decide

Since we are already creating dynamic grammar; why not allow the user to select whether he prefers multiline emphasis or not?

---

On a side note, I think this issue spans across more than merely emphasis. Any inline that spans some indefinite type/amount of content (emphasis, inline-code, strike-through, CriticMark, etc.) has to deal with this. In general, I would say that the default is single-line. For CriticMark though, I think that since its tags are anything but randomly possible/appearing in documents, it would always be multiline.

error in config file

language-markdown disable language-gfm, ok that ist what we want.

but with every opening atom there is a new line in my config file

disabledPackages: [
  "language-gfm"
  "language-gfm"
  "language-gfm"
]

after deinstall language-markdown the problem is solve

Add support for TOML front matter

Reference: atom/language-gfm#111

Atom needs to be reloaded after updating language-markdown; possibly atom-wide issue

Verified. Reproduce:

• installing v0.15
• update to v0.16.2
• create a new document
• switch grammar to markdown
• type * list item and press enter
• the next line will start with a double * * instead of the expected single *

Uncaught TypeError: Cannot read property 'cursors' of undefined

[Enter steps to reproduce below:]

1. ...
2. ...

Atom Version: 1.3.1
System: Mac OS X 10.10.5
Thrown From: language-markdown package, v0.7.0

Stack Trace

Uncaught TypeError: Cannot read property 'cursors' of undefined

At /Users/haiker/.atom/packages/language-markdown/lib/main.coffee:162

TypeError: Cannot read property 'cursors' of undefined
    at Object.module.exports.getEditorAndPosition (/Users/haiker/.atom/packages/language-markdown/lib/main.coffee:162:22)
    at Object.module.exports.toggleTask (/Users/haiker/.atom/packages/language-markdown/lib/main.coffee:177:27)
    at atom-workspace.subscriptions.add.atom.commands.add.markdown:toggle-task (/Users/haiker/.atom/packages/language-markdown/lib/main.coffee:38:96)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:260:29)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:3:61
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:536:16)
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:359:22)
    at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeydown (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:97:36)
    at HTMLDocument.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:3:61)

Commands

     -0:40.7.0 application:add-project-folder (atom-pane.pane.active)
  2x -0:03.7.0 markdown:toggle-task (input.hidden-input)

Config

{
  "core": {
    "themes": [
      "atom-dark-ui",
      "atom-dark-syntax"
    ],
    "projectHome": "/Users/haiker/",
    "openEmptyEditorOnStart": false,
    "disabledPackages": [
      "language-gfm",
      "language-gfm"
    ]
  }
}

Installed Packages

# User
language-gradle, v0.0.3
language-markdown, v0.7.0
language-sql, v0.20.0
markdown-preview-plus, v2.2.2

# Dev
No dev packages

Improve compatibility with default syntax-themes (work in progress)

Current progress of this issue is tracked in PR #83. All information below is retained as a backup.

---

Most markup related styles (primarily used for Markdown purposes incidently) in syntax themes are directly linked to the gfm scope of the language-gfm package. Instead, the more convenient markup scope should be used for styling generic markup. To improve the compatibility with this package (and any other markup related packages) PRs fixing these scopes need to be submitted for all default syntax themes. Somebody has to do it, right?

I am using this issue to track the progress of these connected PRs. The document used to check supported styles is DIVERSITY.md on the dev branch.

todo

• Change the default source from which syntax-themes are created
• Create a drop-in markdown.less file with mappable variables to quickly support syntax-themes.

atom-dark-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

atom-light-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

base16-tomorrow-dark-theme

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

base16-tomorrow-light-theme

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

one-dark-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

one-light-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

solarized-dark-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

solarized-light-syntax

• headings
• italics
• inline-code
• fenced-code
• links (label + link) + images
• link-reference
• horizontal-rule
• list-items (ordered, unordered, task)
• quote
• bold (strong emphasis)
• auto-links
• strike-through
• criticmark (except comments)
• class, id and key=value in special-attributes
• inline html, css and javascript
• gfm references
• emojis
• tables
• escaped characters
• nested inline styles
• front-matter
• entities
• comments

Possible performance issues

Hey @leipert,

When running Timecop I've notived that language-markdown has by far the worst loading and activation times of any packages. Of course, that makes sense because it is 'compiling' itself every time Atom is loaded. On my main machine (27'' imac with a lot of everything), this isn't really an issue. On my Macbook air though, it is definitely noticable (more than half a second extra loading time, last time I checked).

Do you have any ideas how to improve this in the future? I don't consider it an issue per se, but users are complainers.

Support advanced gfm references

See: https://help.github.com/articles/writing-on-github/#references

Improve syntax highlighting by using more conventional scopes

I intend to keep our current purely semantic scopes, and follow the conventions set by language-gfm to automatically support the majority of syntax-themes. The following is a checklist of 'default' classnames that are relevant.

.comment {}
.keyword {}
.storage {}
.constant {}
.constant.escape {}
.variable {}
.string {}
.string.link {}
.punctuation {}
.support {}
.entity {}
.entity.name.class {}
.entity.name.tag {}
.entity.id {}
.meta {}
.none {}
.invalid {}
.invalid.deprecated {}
.invalid.illegal {}

.markup {
  &.bold {}
  &.changed {}
  &.deleted {}
  &.italic {}
  &.heading {}
  &.inserted {}
  &.list {}
  &.quote {}
  &.raw {}
}

• copy html-tag class-names
• check examples with default syntax themes

php isn't highlighted in fenced-code-block

See example in /EXAMPLES.md

Add support for ERB to fenced-code-blocks

As you see above, highlightings are broken, under the erb code block.
It seems some types of language don't work, though only ruby works.

Does this project plan to support other language types?

Roadmap for v0.3

• Thin out the specs:
  • Remove unneccessary repeated elements that provide context unimportant to syntax highlighting
  • Remove duplicates
  • Remove tests aimed at interpretation rather than representation (for instance, uppercase vs lowercase testing, or logical dependencies)
• Support advanced gfm references (#35)
• Add support for TOML front matter (#36)
• Add Markdown Extra flavor (#37)
  • Add special attributes ({}) to headings, fenced code blocks, links and images
  • Defintion lists
  • Footnotes
  • Abbreviations
  • Add specs and examples for Markdown Extra
• language-gfm/issues/40
• Update README (include screenshots, Markdown Extra)

Markdown Preview not triggered within text.md scope

Ok... This is a bit weird. My first time using atom - so let me know if it's something I'm doing wrong.

I've installed the language-markdown package - now I can't open the preview pane.

ctrl+shift+m doesn't work, neither does Packages->Markdown Preview->Toggle Preview.

If I switch the document formatting to "GitHub Markdown", I can turn on the preview. If I switch back to markdown, the preview pane stays there and, seemingly, works.

The only other package I've installed is markdown-scroll-sync

Avoid dependence on the 'pathwatcher' package, in favor of using 'fs'

Convert regexes in grammar to strings

Hey @leipert,
How difficult would it be to add something to /lib/main.coffee when the grammar is loaded that converts any match, begin or end fields that are a normal regex to one of those double escapes strings that the Grammar wants?

That would certainly make writing regexes a lot more pleasurable. Look at the difference:

language-todo doesn't work inside text.md

first idea on pattern loops

As an alternative to our current header rules:

key: 'heading'
containsLoops: true
loopData: {
  level: ['6','5','4','3','2','1']
}
patterns: [
  # Empty headings
  {
    match: '^(?: {0,3})((?:#{1,6})\\s*(?:#*)\\s*)$'
    name: 'empty.heading.md'
    captures:
      1:
        patterns: [
          {
            patternLoop: true,
            template: {
              match: '^(#{<%= level %>})\\s*(#*)\\s*$'
              name: 'heading-<%= level %>.md'
            }
            fixed: {
              captures: {
                1: { name: 'punctuation.md' }
                2: { name: 'punctuation.md' }
              }
            }
          }
        ]
  }
  {
    # NOTE
    # Does it make sense to first do a general check to determine if there is a
    # match for a heading? It seems more logical to test against one match, than
    # to go through all six of them every iteration.
    match: '^((?: {0,3})(?:#{1,6})(?: +)(?:.+))$'
    name: 'heading.md'
    captures:
      1:
        patterns: [
          {
            patternLoop: true,
            template: {
              begin: '^(?: {0,3})(#{<%= level %>})(?: +)'
              end: '(?: ){1}(#*)(?: *)$'
              name: 'heading-<%= level %>.md'
            }
            fixed: {
              captures:
                1: { name: 'punctuation.md' }
                2: patterns: [{ include: '#inline' }]
                3: { name: 'punctuation.md' }
            }
          }
        ]      
  }
]

Embedded code variations (php, erb, etc.) don't work in fenced-code-blocks

See #22 and #43 (both closed as a way of hiding them)

Summary:

The generated fenced-code-blocks for php and erb (and possibly others in the future) don't work because there is something wrong with the scope. I suspect the issue lies in the fact that a .php file has an opening and closing tag to designate which parts are php; the content of the file isn't php by itself! Adding the opening and closing tags to code-examples doesn't work however.

Rewrite README for v1.0 release

• Add an animated gif to showcase the improved list behavior
• Add instructions for syntax-theme support (and possibly list which major themes support standard markup styles)
• Add a list of supported grammar and its limitations
• Add screenshots showcasing the breadth of support in minimal-syntax and minimal-syntax-dark
• Remove unnecessary clutter

Add specs for keybindings and commands

Limit keybindings via [data-language=] selector instead of programmatically