search

asciidoctor / atom-language-asciidoc

⚛ AsciiDoc language package for the Atom editor.
https://atom.io/packages/language-asciidoc
MIT License
42 stars 20 forks source link

order unconstrained monospace before constrained #102

Closed mojavelinux closed 8 years ago

mojavelinux commented 8 years ago

This is primarily an internal change that makes the grammar more accurate.

nicorikken commented 8 years ago

Simple improvement to adhere to the upstream project better, no fuzz.

ldez commented 8 years ago

@mojavelinux can you explain that ?

With the Atom grammar package:

0 *bold* 1 **bold* 2 ***bold* 3 * 4 ***bold** 5 ***bold*** 6 **bold*** 7 *bold***
  [c   ]   [uc        ]             [uc     ]   [uc     ]    [uc    ]    [c   ]

With AsciiDoc Preview:

0 *bold* 1 **bold* 2 ***bold* 3 * 4 ***bold** 5 ***bold*** 6 **bold*** 7 *bold***
  [c   ]   [uc        ][c   ]       [c                   ]   [uc    ][c        ]
                                     [uc    ]   [uc     ]

If I read this: https://github.com/asciidoctor/asciidoctor/blob/v1.5.4/lib/asciidoctor.rb#L1157-L1166.

For me, the section 4 cannot be render as constrained strong with nested unconstrained strong because unconstrained strong is evaluate before constrained strong.

What are the rules?

mojavelinux commented 8 years ago

One very important thing to keep in mind is that Asciidoctor (and AsciiDoc Python) applies substitutions one at a time. Therefore, when the constrained substitutions are applied (for a given formatting type), the unconstrained marks are no longer there. They have been replaced by the converted output (for example, <strong>). Therefore, it's going to be very difficult, if not impossible, for the grammar to do a 100% perfect job. It's literally seeing a different picture than the converter does.

My hope is that this will change once we switch to a formal inline parser. See https://github.com/asciidoctor/asciidoctor/issues/61. Of course, that will slightly change the nature of AsciiDoc, but only in these very extreme edge cases.

ldez commented 8 years ago

Thanks for the explanations.

I note we do a better job than the GitHub parser grammar. (see my comment, I have updated to see highlighting syntax) :smile:

mojavelinux commented 8 years ago

I note we do a better job than the GitHub parser grammar.

:+1: This is by far the best and most informed effort to write a highlighting grammar for AsciiDoc. And we still have room to grow!

nicorikken commented 8 years ago

I noticed this today as well, with the snippets, and the attribute list, we are now at a state of refinement and refactoring, as most basics are present now. Lot of progress since I joined this project 😄 😄