Portable escape syntax for asterisk, add cpp to code samples#92
Portable escape syntax for asterisk, add cpp to code samples#92colin-home merged 2 commits intoMicrosoftDocs:masterfrom Paul-Dempsey:patch-7
Conversation
Paul-Dempsey
commented
Sep 9, 2017
- Different md processors handle character escapes differently. In particular, the OPS markdown processor is in some places different than the GitHub/VSTS/etc previewers. A recent sprint changed the markdown processor, so this topic doesn't render the escaped asterisks properly. Changed these to use html character references, which render properly in all processors/viewers.
- add cpp to c++ code samples
- Different md processors handle character escapes differently. In particular, the OPS markdown processor is in some places different than the GitHub/VSTS/etc previewers. A recent sprint changed the markdown processor, so this topic doesn't render the escaped asterisks properly. Changed these to use html character references, which render properly in all processors/viewers. - add cpp to c++ code samples
|
@Paul-Dempsey, |
|
For both readability and source searchability, escaped markdown is preferred to HTML numeric character references if such an escape exists. For clarity, it's acceptable to switch bold markers ** to __. I'll try an edit to the patch to see if that works. |
Updated escapes to switch ** to __. Babelmark 2 https://johnmacfarlane.net/babelmark2/ seems to find these changes acceptable. Cleaned a little formatting.
colin-home
left a comment
There was a problem hiding this comment.
Approving to move into build.
|
The problem is that the particular markdown escape syntax supported (and in what contexts) depends on the precise markdown processor used, and the markdown backslash is inconsistently handled by the different processors, so character escape usage is inherently non-portable markdown. Attempting to use the markdown escape makes it challenging to assure that you are going to get the correct rendering - the previewer that a given user is happening to be using doesn't necessarily reflect what's going to happen in the OPS pipeline -- there are a variety of authoring environments mentioned in the OPS authoring guide, and most do NOT have a previewer that matches OPS. The reason these topics were broken is because OPS changed the markdown parser they were using, but somehow the corresponding updates in the authored content didn't happen. Presumably, OPS is now using a parser that is much closer to what you see in the GitHub editing interface, but it is still different in some cases (and not just for the OPS extensions, which no previewer I've seen yet supports). This is an area where there are definitely tradeoffs, and I chose to fix a definitely broken page in the most portable way because I did not have confidence that the GitHub editor would render them in the same way as the OPS pipeline. I'm not saying you have to use my solution - just explaining why I did it the way I did it. I've done it my way in my content set because I don't want my content to break again on the next OPS parser iteration (and I have a lot of picky syntax with special characters). |
|
I'll never complain about people willing to fix issues in our docs. :) If the raison d'etre for markdown is readable plain-text composition, and portability across markdown interpreters is so broken that unreadable escapes are required for consistent output, something is seriously wrong. The point of publishing our sources in markdown is to make editing accessible to anyone, with a minimal learning curve. The use of HTML or numeric escaped entities on common everyday elements is actively hostile to that intent. I can't do much about other markdown interpreters, but if simple markdown escapes are broken in OPS, then it's time to file a bug against OPS, not throw in the towel on readability. Rant not really aimed at you; more at the state of markdown in general and markdown on GitHub in particular, with its complete disregard of the rules for wrapping on single newlines and breaking on two. But for OPS, I know people in Shanghai. We can get it fixed. |