jrblevin/markdown-mode

Emacs Markdown Mode

markdown-mode's Issues

User-preferred case in GFM language names

For the first GFM fenced code block inserted in a file, the capitalization in the pre-specified language list seems to dominate what is typed by the user. For example, if one enters "Fortran" as the language name the empty code block will be inserted as

``` FORTRAN

```

while one would have expected to instead see

``` Fortran

```

(This was previously discussed in #54, but since that PR was merged I am just opening a new issue as a reminder.)

Brackets order is wrong

Please note that I tried disabling autopair, but the bug remained. This is critical for me. I have to use Sublime now :(

(GFM) Often fails to properly detect start/end of PRE-formatted code blocks

GFM often fails to detect the start and/or end of triple-backtick PRE-formatted code blocks.

Example:

https://raw.githubusercontent.com/mcandre/hello-thrift/master/README.md

Indentation of code blocks after pressing enter on Emacs 24.5.1

Maybe it's me, I'm new to markdown mode on Emacs. I never used it before, so I can't compare with a previous version of Emacs. But it seems that indentation of code blocks is broken.

Let's say I want to write a code block, I hit Tab, then type my first line. It gives:

I'm gonna write a code block:

    my first line of code█

Now, when I hit enter, my line is brought back to the beginning of the line:

I'm gonna write a code block:

my first line of code
█

Does anybody else experience that ? I saw that ticket #16 looks a little bit like this, maybe it's related...

Anyway, the workaround is simple: I go back to the first line, hit Tab to reindent, go to the second line, hit Tab to indent, write some code, hit Enter. And at this moment the indentation remains, and I can keep on writing my code block. The problem only happens for the first line of the code block.

README.md: Specified Arch (AUR) package (`emacs-goodies-el`) does not exist

The arch (AUR) package ``formarkdown-mode does not exist at the specified location https://aur.archlinux.org/packages/emacs-goodies-el/ in README.md. (And could not locate anywhere else).

Regards,
Ronald

Lines beginning with hash symbol in literal code blocks treated as headers

For the purposes of commands such as outline-next-visible-heading and outline-forward-same-level, it is not expected that lines beginning with the # symbol in literal code blocks be treated as headers.

For example:

### Third level ###

* A list item
* and another
  with some overhang
   + and a sublist
     with overhang
- And a third with a different marker

### Third level number two ###

~~~ {.bash}
#!/bin/bash

# In a code block, this shouldn't be a header
~~~

### Level two again

followed by some body text

unexpected test failure: test-markdown-ext/live-preview-exports

running "make test" on Debian testing (emacs 24.5), I get

Test test-markdown-ext/live-preview-exports backtrace:
#[nil \306P\307\310\311\312#\311313 \314\216\315\216\316\n!
#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316"\317\320%DC
funcall(#[0 "\306\307!r\211q\210\310\311\312\313\314\315!\316"\31
ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314"\315\316%DC\2
funcall(#[0 "r\304 q\210\305 )\306\307\310\311\312\313!\314"\315
ert-run-test([cl-struct-ert-test test-markdown-ext/live-preview-expo
ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test t
ert-run-tests(t #[385 "\306\307"\203D\211\211G\310U\203\211@\20
ert-run-tests-batch(nil)
ert-run-tests-batch-and-exit()
command-line-1(("-l" "ert" "-l" "../markdown-mode.elc" "-l" "markdow
command-line()
normal-top-level()
Test test-markdown-ext/live-preview-exports condition:
(ert-test-failed
((should-error
(markdown-live-preview-mode))
:form
(markdown-live-preview-mode)
:value t :fail-reason "did not signal an error"))

It seems to have something to do with the state of what libraries are loaded (maybe eww?) since if I run the tests interactively it succeeds on repeating the test.

Pleas make a stable release

It's be a few years, and several hundred commits. Lack of stable releases means lack of updates in various places including marmalade, melpa-stable, and linux distros.

Pandoc MD item lists

Pandoc MarkDown supports item, or definition, lists. They look like this:

This is the item title
:    This is the definition paragraph which
     may span several lines

If I put the cursor over the definition paragraph and press M-q (fill paragraph), emacs messes up everything. This makes it totally unworkable for texts with this kind of lists.

As a quick fix I added the ":" charater to the regexp that recognizes list items.

(defconst markdown-regex-list
  "^\\([ \t]*\\)\\([0-9#]+\\.\\|[\\*\\+-:]\\)\\([ \t]+\\)"
  "Regular expression for matching list items.")

This allows me to enter the definition above as:

This is the item title

:    This is the definition paragraph which
     may span several lines

and have M-q work. This is valid Pandoc Markdown, but it would be nice if I could omit the blank line.

Thanks for making markdown-mode available!

Commit 23113fa broke fenced code blocks

Currently, trying to edit anything immediately after a fenced code block (in either markdown-mode or gfm-mode) only results in Emacs completely freezing up. Try this:

> cat hello.md
```
hello
```
> emacs --no-init-file --load markdown-mode.el hello.md

Now go to the end of the file and try to insert anything. Nothing happens (except for 100% CPU usage).

Bisecting reveals that the problematic commit is 23113fa.

Fill-paragraph treats lines starting with italics as bullets

Just ran into this today, and it's admittedly a bit of an edge case. If a bullet list item stretches over multiple lines (through the use of fill-paragraph), and one of those lines starts with a word marked with asterisks for italics, later uses of fill-paragraph will treat those asterisks as bullets rather than italic markers.

To reproduce: copy the following into a markdown-mode buffer in emacs and do a fill-paragraph (Meta-q) on it twice. The second time it will add bullet markers to 3rd and 4th lines.

* foo bar baz foo bar baz foo bar baz foo bar baz foo bar baz foo bar baz foo *bar* baz foo bar baz foo bar baz baz foo bar baz foo bar baz baz foo bar baz foo bar baz baz foo bar baz foo bar baz baz foo bar baz foo bar baz baz foo bar baz foo bar baz

I don't know if this is fixable, but I'm reporting it in case anyone can think of a good solution.

Apparent Parsing Bug

The following markdown code seems to cause a parser bug.

```
{
 :user {
   :repositories [["clojars" {:sign-releases false}]]
   :plugins [
      [lein-cloverage "1.0.6"]
   ]
 }
}
```

Steps to reproduce:

1. Write the above content to a file with markdown-mode disabled (or using an editor other than emacs)
2. Open the file in emacs and enable markdown-mode
3. Attempt to quit emacs via C-x C-c

Expected Behavior: Emacs quits as normal

Actual Behavior: An error on the mode-line saying...

Not a Tramp file name: "/"clojars"_{:sign-releases_false}.md"

At this point emacs starts behaving pretty strangely, and can't be closed via M-x kill-emacs. I've ended up killing the pid from the command-line and restarting.

Could this string being sending some regex into a tizzy?

feature request: convert links

i often end up converting links from:

[foo](http://example.com)

to:

[foo][]

 [foo]: http://example.com

The rationale is that writing the former is more natural, but looks more messy, so i start by doing that but often end up converting to the latter because it formats better.

I ended up recording this awful keyboard macro to do this more or less automatically:

C-s         ;; isearch-forward
](          ;; self-insert-command * 2
<left>          ;; left-char
C-SPC           ;; set-mark-command
C-r         ;; isearch-backward
[           ;; self-insert-command
M-w         ;; kill-ring-save
M-C-s           ;; isearch-forward-regexp
C-q         ;; quoted-insert
2*LFD           ;; electric-newline-and-maybe-indent
<left>          ;; left-char
<right>         ;; right-char
C-y         ;; yank
RET         ;; markdown-enter-key
<left>          ;; left-char
:           ;; self-insert-command
SPC         ;; self-insert-command
C-r         ;; isearch-backward
C-y         ;; yank
C-r         ;; isearch-backward
10*<right>      ;; right-char
10*<left>       ;; left-char
<right>         ;; right-char
C-s         ;; isearch-forward
](          ;; self-insert-command * 2
<left>          ;; left-char
<deletechar>        ;; delete-forward-char
[]          ;; self-insert-command * 2
C-SPC           ;; set-mark-command
C-s         ;; isearch-forward
)           ;; self-insert-command
<left>          ;; left-char
C-w         ;; kill-region
<deletechar>        ;; delete-forward-char
C-u C-SPC       ;; set-mark-command
C-u C-SPC       ;; set-mark-command
C-u C-SPC       ;; set-mark-command
C-y         ;; yank
<home>          ;; move-beginning-of-line
SPC         ;; self-insert-command
C-u C-SPC       ;; set-mark-command
C-u C-SPC       ;; set-mark-command
C-u C-SPC       ;; set-mark-command
M-q         ;; fill-paragraph

As a lisp expression:

;; horrible way of converting [foo](link) to [foo][] [foo]: link
(fset 'md-convert-link
   [?\C-s ?\] ?\( left ?\C-  ?\C-r ?\[ ?\M-w ?\C-\M-s ?\C-q ?\C-j ?\C-j left right ?\C-y ?\C-m left ?: ?  ?\C-r ?\C-y ?\C-r right ?\C-s ?\] ?\( left deletechar ?\[ ?\] ?\C-  ?\C-s ?\) left ?\C-w deletechar ?\C-u ?\C-  ?\C-u ?\C-  ?\C-u ?\C-  ?\C-y home ?  ?\C-u ?\C-  ?\C-u ?\C-  ?\C-u ?\C-  ?\M-q])

yes, this is horrible. i started writing this as a function but then got tired and wondered if anyone else worked on this. here's how far i got so far:

(defun anarcat/markdown-convert-link ()
  (interactive)
  (search-forward "](")
  (search-forward ")")
  (kill-region) ;; the link
  ;; need to kill the parens too
  (save-excursion
    (search-forward "\n\n")
    (yank)
    ;; need to save point here to come back
    )
  (search-backwards "]")
  (search-backwards "["]
  (kill-ring-save) ;; the text
  ;; now go back to the point and format the text and all
  )

i don't like it one bit so far... anyone else fixed up something like this?

Markdown documents don't have syntax colouring anymore

Hi,

I upgraded markdown-mode via elpa to markdown-mode-20150724.2116 recently and now I'm not getting any syntax colouring. Other things seems to work fine.

Any idea what may have changed recently? Was it in the general area of syntax colouring?

Thanks in advance for any help.

Ability to disable markdown-insert-gfm-code-block prompt

I appreciate the option to specify a language name for gfm triple backticks pre-formatted code blocks, but 99% of the time, I always want to skip it.

Could we introduce a configurable variable for whether the prompt is raised, or nil, or some preferred default language name is used?

De-denting and lag

There are 2 issues I've noticed on Emacs 24.5.1 OS X 10.10.5.

Take the file:

test

* item 1

1. When I hit enter at the end of the "item 1" line this will be de-dented to the beginning of the next line.
2. I have a markdown file with about 2300 lines and entering data into this file is pretty laggy.

font-lock bold links

Both of these render as bold links in Marked 2, multimarkdown, github and CommonMark:

**[bold link](http://www.link.com/)**
[**bold link**](http://www.link.com/)

However in markdown-mode the font-locking shows them as regular (unbolded) links. It would be nice if the the text was shown as bold. Perhaps the append keyword in the bold and italic parts of font-lock-keywords would help.

gfm-mode and line wrapping

I think there is some confusion around what GitHub Flavored Markdown actually is. There are actually two levels:

1. https://help.github.com/articles/github-flavored-markdown/ -- This is the real "GitHub Flavored Markdown", which has things like different behavior for underscores, URL autolinking, and fenced code blocks. This is what most people probably want to use.
2. https://help.github.com/articles/writing-on-github/ -- This is "GitHub Flavored Markdown along with some additional features", which has different newline behavior, task lists, and auto-linked references to issues and such. This only applies to writing issues and comments on the GitHub site.

gfm-mode apparently wants to combine both in one, but that seems wrong. If I write a README.md for including in a GitHub repository, then I do want the URL autolinking and the fenced code blocks, but I don't want the newline-is-significant behavior.

Since only the most die-hard users would use Emacs for writing issues and comments on GitHub, I would remove support for the second variant altogether. In practice, the difference is small, and arguably it is not the job of a major mode to fiddle with visual-line-mode anyway.

Ordered list renumbering freeze

When I have such content

a

1. a
3. c
2. b

And invoke the "C-c C-c n", Emacs will freeze.

But if I remove the empty line after "a" (the second line), then the renumbering works fine.

Link to this GitHub repo in MELPA description

Please display a link to the GitHub repo in the MELPA description, so that it's easier to find the GitHub repo.

An error in command `markdown-standalone' leads to the out-of-order html output.

The code:

 (unless (markdown-output-standalone-p)
    (markdown-add-xhtml-header-and-footer output-buffer-name))
 (goto-char (point-min))

in https://github.com/jrblevin/markdown-mode/blob/master/markdown-mode.el#L4421-L4423 would lead to the out-of-order html output. The html content generated by markdown-command should be placed in the middle of the xhtml header and footer.

Here is the code fix:

(goto-char (point-min))
(unless (markdown-output-standalone-p)
  (markdown-add-xhtml-header-and-footer output-buffer-name))

option to add space after gfm codeblocks

Similar to #18, I would really really really appreciate it if we could set an option to add a space between the codeblock delimiter and the language, like this:

``` language

instead of:

```language

I know it's such a minor thing but this and #18 are the only things that really throw me off from this otherwise amazing markdown package (coming from vim, it's lightyears ahead). I love that I can type the three backticks and then it prompts me for the language automatically, as well as there being the other bind, but I always have to go and add the space manually to remain consistent with the rest of my documents, which breaks my rhythm.

I hope it's not that big of a deal to implement that you wouldn't mind to. I would reaaally appreciate it!

Function to toggle gfm checkbox

I find the following function useful to toggle gfm style checkboxes with the mouse. Perhaps it's useful to include in markdown-mode. Maybe it would be better implemented using make-button.

(defun hrm-markdown-toggle-gfm-check-box (event)
"Click in a gfm task list and toggle its state."
(interactive "*e")
;; go to where the event occurred
(set-buffer (window-buffer (posn-window (event-start event))))
(goto-char (posn-point (event-start event)))

;; assume on a list line (so false positive if [ ] in middle of text)
;; point could be at either position inside the checkbox
;; " [| ] " or " [ |] " or " [|X] " or " [X|] "
(save-match-data
(save-excursion
(forward-char -2)
(let* ((box-regexp " [([ xX])] ")
(at-box (looking-at box-regexp)))
(unless at-box
(forward-char -1)
(setq at-box (looking-at box-regexp)))
(if at-box
(replace-match (if (string= " " (match-string 1)) "x" " ")
nil nil nil 1))))))

Please consider changing the "new list item" hotkey

Rationale: Emacs uses C-c C-j to create new items in some list environments, most notably LaTeX related modes. AFAIK, C-j is used for indentation in some programming modes, but I'm not used to using it.

Do you have any strong feelings for using this particular combo for this particular funcion? Would it be possible to use C-c C-j to create new list items instead? It would be easier users of content modes to use the same hotkeys for the same purposes in content-oriented modes.

BTW, I'm fairly new to markdown and GFM, and just found out about your emacs mode. Your docs accelerated my markdown learning. Kudos for both the code and the docs! Thanks!

(GFM): Options to disable triple backtick automation

I would appreciate options to disable:

• the which-language-would-you-like prompt
• automatic closing of triple backticks

scripts/get-recognized-gfm-languages.el skips languages with spaces

For example, Emacs Lisp:. This is because the regular expression matches on those not containing spaces.

Recognize definition list definitions as paragraph starts

Using a line starting with a colon to denote a definition list is a widely used Markdown extension. Adding the following line to paragraph-start allows one to fill such definition paragraphs without having them collapse with the previous line (the defined term).

diff --git a/markdown-mode.el b/markdown-mode.el
index e61ef78..7ef0889 100644
--- a/markdown-mode.el
+++ b/markdown-mode.el
@@ -5090,6 +5090,7 @@ before regenerating font-lock rules for extensions."
                     "[ \t]*[*+-][ \t]+" ; unordered list item
                     "[ \t]*\\(?:[0-9]+\\|#\\)\\.[ \t]+" ; ordered list item
                     "[ \t]*\\[\\S-*\\]:[ \t]+" ; link ref def
+                    "[ \t]*:[ \t]+" ; definition
                     )
                   "\\|"))
   (set

Feature request: Support for Pandoc Markdown's inline footnotes

The syntax of Pandoc Markdown's inline footnotes, per manual, is

Here is an inline note.^[Inlines notes are easier to write, since
you don't have to pick an identifier and move down to type the
note.]

Would you consider supporting this syntax? A quick patch to enable this would be

diff --git a/markdown-mode.el b/markdown-mode.el
index 524b311..b760f58 100644
--- a/markdown-mode.el
+++ b/markdown-mode.el
@@ -1173,6 +1173,13 @@ Group 1 matches the opening square bracket and carat.
 Group 2 matches only the label, without the surrounding markup.
 Group 3 matches the closing square bracket.")

+(defconst markdown-regex-inline-footnote
+  "\\(\\^\\[\\)\\([^]]+\\)\\(\\]\\)"
+  "Regular expression for an inline footnote ^[footnote text].
+Group 1 matches the opening caret and square bracket.
+Group 2 matches the footnote text, without the surrounding markup.
+Group 3 matches the closing square bracket.")
+
 (defconst markdown-regex-header
   "^\\(?:\\(.+\\)\n\\(=+\\)\\|\\(.+\\)\n\\(-+\\)\\|\\(#+\\)\\s-*\\(.*?\\)\\s-*?\\(#*\\)\\)$"
   "Regexp identifying Markdown headings.
@@ -1886,6 +1893,9 @@ See `font-lock-syntactic-face-function' for details."
    (cons markdown-regex-footnote '((1 markdown-markup-face)   ; [^
                                    (2 markdown-footnote-face) ; label
                                    (3 markdown-markup-face))) ; ]
+   (cons markdown-regex-inline-footnote '((1 markdown-markup-face)   ; ^[
+                                          (2 markdown-footnote-face) ; footnote text
+                                          (3 markdown-markup-face))) ; ]
    (cons markdown-regex-link-inline '((1 markdown-markup-face nil t)     ; ! (optional)
                                       (2 markdown-markup-face)           ; [
                                       (3 markdown-link-face)             ; text

I haven't considered if there would be any undesirable side effects.

multiline italics face when not wanted

I'm using Package-Version: 20160109.957 with the mac homebrew emacs-24.5-mac-5.15 (which is 24.5.1).

I have a list as follows:

• something about function foo_bar
• something else about foo_bar

Everything between the two _ is in markdown-italic-face. I don't think it should be. Marked 2 doesn't display it as italics and neither does GitHub.

markdown-italic-underscore is nil.

indentation of multi-line list items after pressing Enter on Emacs 24.5.1

I regularly use two different versions of Emacs (24.3.1 and 24.5.1) and I've noticed that between them, the behavior of newline-and-indent has changed:

 (defun newline-and-indent ()
   (interactive "*")
   (delete-horizontal-space t)
-  (newline)
+  (newline nil t)
   (indent-according-to-mode))

By extension, this means that the behavior of markdown-enter-key has changed as well. Whereas in Emacs 24.3.1, when I press Enter at the end of a multi-line list element, this happens:

- list
  - nested list with long lines which need to be
    hard wrapped
    █

... in Emacs 24.5.1, this happens instead:

- list
  - nested list with long lines which need to be
  hard wrapped
  █

(In both cases, markdown-indent-on-enter is set to t.)

What is the intended behavior? Personally, I think the first one is more desirable, because it preserves the nice formatting (with hanging indentation) of multi-line list elements, but irrespective of what I think, would it be possible to make it consistent either way?

And cheers for all the great work on markdown-mode by the way, thank you ever so much :)

zsh:1: command not found: markdown

Markdown should be installed for Markdown-preview(apt-get install markdown).

markdown-next-paragraph chokes on certain tables

I have a table with a large blank first cell and markdown-next-paragraph (as well as previous) seems to choke on it. C-g stops and I can manually go over it.

version 2.0

Table:

|                   | Percentage | Amount (@ 75k) |
|-------------------|:----------:|---------------:|
| Everything Else   |19%         | $14,250        |

Markdown mode breaks Emacs

markdown-mode 20151224.808
GNU Emacs 25.1.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8) of 2015-12-30.
It totally breaks and exit Emacs when typing text in markdown-mode. When I switch major mode to text-mode everything is fine. It is easy to reproduce this, but because it exits Emacs I can't provide any useful information; hence,

• open .md file
• type few characters and try to save changes
• Emacs quits without any messages.

imenu is confused by GFM fenced code blocks

Given the markdown:

# Heading

## subheading

```
foo
# bar
baz
```

## another subheading

Calling 'M-x imenu' erroneously shows 'bar' as a heading.

This makes imenu less useful, and is also causing ardumont/markdown-toc#13

Markdown mode is getting slow

I'm trying to fight frightening typing latency in my Emacs. It LAGS WHEN I TYPE. It's slower than an IDE. It's become really slow.

Please think twice when you put heavy code into hooks that are effectively executed after every key-press. I'm already thinking about writing state-less Smartparens that does not skyrocket latency. I already have to invent something to deal with the same issue with Flyspell. Heck, I have other things to do except for constantly making sure that I can type in Emacs normally. Every package puts a little bit of not-very-fast code into hooks, and then it all sums up. This is a real problem for me now. I don't even know why the heck I need to scan and fontify wiki links. What sort of Wiki? Can you make a variable that would turn off all these hooks expect for very-very basic ones? Or should I rewrite parts of markdown-mode in my config in order to be able to use it?

Coloring miss

https://github.com/supermomonga/darui.io/blob/master/README.mkd

My personal website [だるい](#)'s source repository.

# is link target, but it seems to be colored as heading.

Generated markdown in message buffer

The markdown function uses shell-command-on-region, which in addition to writing to the destination buffer, apparently also prints the output to the echo area and the *Messages* buffer. Maybe call-process-region or something similar should be used instead.

Can markdown-mode cause problems with query-replace?

Hi there.

I believe, I'm experiencing an issue with the Emacs query-replace function, which in the end might be caused by the latest development versions of markdown-mode from Melpa.

Let my try to explain. Let's say I've a simple Markdown file, which contains a simple bulleted list of links to a number of images in a directory

* [abcdeg](/xyz/pic[1-20].jpg)
* [abcdeg](/xyz/pic[1-20].jpg)
…

and the latest markdown-mode loaded (20160223.537 after having Emacs terminated and restarted).

Then I execute "M-x query-replace" and enter "/xyz/" to be replaced by "/klm/". Then all occurrences of "/xyz/" are highlighted and I should be able to replace all occurrences one by one by using the Space key or all at once by hitting the ! key. What I'm experiencing however is, that the first occurrence is replaced and then query-replace basically stops and I'm back to editing. In the message buffer I see "replace-match-maybe-edit: Args out of range: 1336".

The reason, why I believe markdown-mode might have something to do with this behavior is, that I put the buffer into simple text-mode (M-x text-mode). Then query-replace worked as expected.

Additionally I also replaced the markdown-down.el file with the one from 2.1 and byte-compiled it and completely restarted Emacs (simple loading of the byte-compiled file does not seem enough). And with the 2.1 markdown-mode loaded query-replace also worked as expected.

Hopefully I don't pickup any residue from something else I've configure in my Emacs startup. I'm experiencing the described behavior on Windows and Linux Emacsen, which share cloud synced initialization files.

BTW, really thank you so much for a really great Emacs Major mode.

crazy buffer-file-name: nil, file-modified-p: t

Create a file containing the following:

---
x: x

---
`x`

then open it in markdown-mode in emacs-24.5.1

For me, the buffer loses its relationship to a file and is marked as modified.

option to use lowercase language name in gfm blocks

First of all, woah!! Thanks a lot @cosmicexplorer for your great work on #54!

It looks and seems to work beautifully! I had been following what seemed to me like a convention which was to use the lowercase representation of language names. The implementation of #54 seems to use the capitalized language, e.g. JavaScript or Python versus javascript or python. I know it's such a minor gripe! But I was wondering if you could possibly add an option to perhaps (downcase chosen-candidate) before inserting it?

I already have many codeblocks that use the lowercase names (which I really prefer) and everyone else I've seen does the same thing, so I'm not too eager to break with that convention and have mixed styles.

Feature suggestion: Support GFM YAML metadata block

Some Markdown implementations, e.g., GFM and Pandoc, support YAML metadata blocks. For GFM (according to testing, since it seems undocumented) the YAML block must start at the beginning at the document (even blank lines before it are not allowed) and be wrapped in --- (exactly three dashes) at the opening and closing, so an example document would be

---
title: README
author: Zhiming Wang
date: January 8, 2016

---

This is an example GFM document with a YAML metadata block.

and this will be rendered like

Note that the blank line after the closing --- line is optional.

(Pandoc, on the other hand, has very lax rules for YAML metadata blocks, which allows them to be placed anywhere in the document, and allows closing with ... instead of ---. But Pandoc Markdown doesn't need to be supported.)

Currently, the line immediately above the closing --- is interpreted as a setext header, which looks rather weird (especially if you have a real header):

Would you please consider supporting the metadata block? I suppose the block itself could be highlighted just like a fenced code block, and I suppose it shouldn't be too hard to adapt the parsing code of fenced code blocks to this particular block. Thanks.

C-u M-RET doesn't preserve list type

Putting the point after "AAA" in the following sample and pressing C-u M-RET inserts "1." (properly deindented) instead of "*":

1. A
    * AA
        1. AAA

That is, it produces

1. A
    * AA
        1. AAA
    1.

instead of

1. A
    * AA
        1. AAA
    *

Thanks to @cpitclaudel for reporting this.

syntax highlighting issues

I'm thinking about making the switch from vim (and vim-pandoc) to emacs. There are some noticeable differences in the way that Markdown mode (and pandoc minor mode) handles syntax highlighting in comparison to vim-pandoc-syntax. For example, markdown mode highlights only the first line of footnotes. This seems to be a problem for block quotes that don't have a > for every line as well. Emphasis and bold do not show in block quoted text. Markdown mode also fails to highlight raw latex.

Unfortunately I know nothing about emacs lisp or how to write syntax highlighting in elisp, so I can't be of any immediate help. But is there any intention of trying to get markdown mode highlighting on par with vim-pandoc's highlighting? In any case, thanks for writing a great emacs mode!

why re-read from init-buf-string in markdown-export?

I'm puzzling over some of the code in markdown-export. After running markdown-after-export-hook, if the buffer is modified by any of the hooks or markdown-standalone, it is re-read from that initial state init-buf-string. Why is that? snip here:

      (run-hooks 'markdown-before-export-hook)
      (markdown-standalone output-buffer-name)
      (with-current-buffer output-buffer
        (run-hooks 'markdown-after-export-hook)
        (save-buffer))
      ;; if modified, restore initial buffer
      (when (buffer-modified-p init-buf)
        (erase-buffer)
        (insert init-buf-string)
        (save-buffer)
        (goto-char init-point))

Is there any reason why this is happening? It doesn't seem to affect anything normally, but I'm working on an asynchronous-export feature for fun (#56) and this erases any input the user has entered from the time export begins to the time the process ends.

turning off italics via underscores doesn't work

Test lines:

• foo _bar_zot
• foo_bar_zot

In markdown-mode both lines are in italics face between the _
In gfm-mode only the first line has italics face

In both cases markdown-italic-underscore is nil. I would think that with a nil value I'd need to use * to get italics for emphasis and that text would be ignored. I'd like to use plain markdown-mode (not gfm-mode) and still be able to write notes with variable names (with underscores) in them.

what does expected test failure mean?

Noticed this when I was running tests previously. What does :expected-result :failed mean? It's kinda confusing when I view the test results and see "failures: 4", even when they're expected. Does that mean the functionality hasn't been implemented yet? If it's in place if (should-not, I would think it would make more sense to just do that.

(ert-deftest test-markdown-font-lock/blockquote-link ()
  "Test font lock for links inside of a blockquote."
  :expected-result :failed
  (markdown-test-string
   "> [link](url)"
   (markdown-test-range-has-face 1 13 markdown-blockquote-face)
   (markdown-test-range-has-face 3 8 markdown-link-face)
   (markdown-test-range-has-face 9 13 markdown-url-face)))

(ert-deftest test-markdown-font-lock/blockquote-comment ()
  "Test font lock for comments inside of a blockquote."
  :expected-result :failed
  (markdown-test-string
   "> <!-- comment -->"
   (markdown-test-range-has-face 1 18 markdown-blockquote-face)
   (markdown-test-range-has-face 3 18 markdown-comment-face)))

;; and others

MELPA: Link to this GitHub repo

Please have the MELPA package link to this GitHub repo to make it easier to find.

option to not surround header in atx hashes

It'd be nice if we could choose not to surround a header with atx hashes, e.g.

## this is my header

instead of

## this is my header ##

However, markdown-mode seems to force it as you can see on this line.

markdown-mode hangs Emacs

Hi,

I work on a fairly large markdown file (126k) and commit 86e0c76 (from Dec 16) hangs Emacs regularly (it lags when I type fast, lags when I use scroll-up-command or scroll-down-command, etc.). Everything works fine with the previous commit. I also tried with a minimal init file, only requiring markdown-mode, and the problem is the same.

I'd like to be able to provide more details here but I don't know how to proceed.

Thank you

Markdown-mode navigation and cycle ignore R code chunk

Hi @jrblevin,

I use markdown-mode all time. This Emacs mode is fantastic.
However, most part of time I'm working with code chunks of R language. In R, comments are preceded by hashs like markdown sections. This is the problem, because I like cycle (S-TAB) and navigation across sections (C-c C-{n p u d}) but R comments inside code chunks are also visited. This code chunk can have a lot of comments (because are class tutorials). I would like ignore text inside chunks to make navigation more precise and fast. I tried use #', another valid comment prefix in R, but markdown mode still got it. I tried also indent my comments by one space, bun didn't work to. A typical code chunk is

```{r}
# Plot data.
plot(dist ~ speed, data = cars)
```

When mark is inside this chunk, Emacs is at ess-mode. Maybe this can be used to narrow S-TAB and navigation imposing to do only for lines at markdown-mode. Do you have any idea how can ignore the code chunks?

Thanks.