Some questions about bold/italic syntax definitions and some other issues.

[IvanAnishchuk]

1. Why are bolds/italics with whitespaces working inconsistently? Asterisks/underscores surrounded by whitespace (in vanila Markdown, at least) be treated like literal asterisk or underscore while in any other case (except special usage: rules, lists, etc.) it should be treated like italic (I think option for GFM might be good, to keep variable names and stuff in order). I'm not sure about double and triple underscores, surrounded by whitespace (should be be treated literally or as bold/bold italic?), it's not clear in docs and must be checked in implementations' source code, but what we have now is just inconsistent anyway.

Also (see comments below) for some reason we have different syntax definitions for underscores and asterisks so underscores inside the word produce very strange formatting (while asterisks do not).

Illustration:

2. Why are they all oneline? I don't remember markdown documentation insisting on that and all the implementations I know work OK with multi-line formatting, e.g github:

multi-line italic

3. Horizontal rule. Markdown syntax definition says that three or more hyphens, asterisks, or underscores on a line by themselves should work. But 1) most of the variants mess up with italic/bold syntax and 2) most of them (ones with the whitespace, I think) seem to be triggering list syntax (vim tries to add a symbol after I hit return).

Illustration:

4. Lists, rules, and quotes. vim-markdown is using comments for auto-formatting lists and quotes currently but probably everyone knows that that's sub-optimal: list items and quotes might be multi-line with identations and there's no way to do it with comments, there is no way to insert an empty line between list items, also there's no way to "blacklist" horizontal rules from being treated like comments. I don't even count the inability to auto-format ordered lists, it's obvious.

I understand that another implementation will necessarily be rather complicated but it seems like what we need anyway. Maybe removing current "comments" and doing nothing would be even better that the current behavior. Anyway, I've no idea yet how to implement this properly, so feel free to suggest and discuss.

I'm willing to fix this myself, but I could use some guidance on whether some of the bugs are actually features and where's the right place to fix. (It's continuation of #86 )

UPD: added 4 and edited 1

[Kynde]

Italics detection is certainly wonky:

- epoll handling for E_TYPE_EXEC in s_ssl_connection

is highlighted in vim like:

- epoll handling for E_TYPE<i>_EXEC in s_</i>ssl_connection

and that's just wrong.

[IvanAnishchuk]

I should mention that I've found a relevant piece of documentation: "if you surround an * or _ with spaces, it’ll be treated as a literal asterisk or underscore." So let's keep that part the way it is now just making it work consistently (i.e. the same way for asterisks and underscores).

@Kynde Yes, it is wrong. Although the proper result with vanilla Markdown should be something like

- epoll handling for E<i>TYPE</i>EXEC in s<i>ssl</i>connection

and you're not gonna like it anyway. Option for GFM syntax would be nice for stuff like this.

[IvanAnishchuk]

I believe, italics syntax for vanilla should be like that:

start="^_\S\@=\|\\\@<!_\S\@=\|\S\@=\\\@<!_" end="\S\@<=\\\@<!_\|\\\@<!_\S\@<="

but I'm not exactly sure what GFM version should look like... My guess is something like that, but I'm not exactly sure:

start="\(^\|\s\)\@<=_\S\@<=" end="\S\@<=\\\@<!_\(\s\|$\)\@="

[IvanAnishchuk]

Ok, someone pls check out my new bold/italic rules in #163 (no GFM option yet, only vanilla syntax). Unit tests as well (can someone help me with running them locally?).

[cirosantilli]

Please keep one question per issue. The tinier the better as long as self contained.

[refparo]

Bold/italic syntax doesn't work when there's no space before the first *. For example, a *b* is highlighted but a*b* isn't highlighted, which should look like ab. This is especially important for documents written in CJK languages.

without spaces:

with spaces (which looks strange in Chinese):