6

I suspect the automated CommonMark migration messed up the formatting of this answer.

Before the migration to CommonMark: https://web.archive.org/web/20200515072655/https://unix.stackexchange.com/questions/136371/how-to-download-a-folder-from-google-drive-using-terminal

enter image description here

After the migration to CommonMark: https://web.archive.org/web/20200820183944/https://unix.stackexchange.com/questions/136371/how-to-download-a-folder-from-google-drive-using-terminal

enter image description here

There was an edit between the two archive.org snapshots but it didn't affect that portion of the answer: https://unix.stackexchange.com/posts/580498/revisions

0

3 Answers 3

9

For full context: the Markdown source of the text in your screenshot:

> Access denied with the following error:

>         Too many users have viewed or downloaded this file recently. Please
        try accessing the file again later. If the file you are trying to
        access is particularly large or is shared with many people, it may
        take up to 24 hours to be able to view or download the file. If you
        still can't access a file after 24 hours, contact your domain
        administrator.

> You may still be able to access the file from the browser:

>         https://drive.google.com/uc?id=1LC5iVcvgksQhNVJ-CbMigqXnPAaquiA2

There was no automated migration done for that answer. It was your edit that resulted in the answer being re-rendered.

First, remember that when a post is made or edited, it is only rendered once, and the HTML from that render continues to be served even though changes are made to the renderer. Re-editing a post will cause it to be rendered again, using the current version of the render. (This gets confusing when looking at revisions, as those behave differently and always render with the current version, but that's besides the point here.)

When the system went through and performed automatic edits to posts as part of the CommonMark migration, it checked to see if its automated edit would result in the rendered HTML being the same as the previous cached HTML from the last edit, made under the prior renderer; if it couldn't automatically edit the post so its rendered HTML would be the exact same, it left the post alone and didn't perform any automatic edit, and so the previous rendered HTML would continue to be served.

The rules list for that automated script was extremely basic, however, covering only the most common issues (e.g. ##Headings, block quotes without continuity, etc.), and excluding subtle nuances. This did, however, mean that if a post did contain such a subtle nuance, no matter how minor, it would prevent the post from being edited by the script, and so other issues that were covered by the script wouldn't be fixed.

In your case, the markup above uses two things that were compliant with the older renderer, but not with the new one:

  • Non-contiguous block quotes. Under the old renderer, two lines with block quotes would always render as a single contiguous block quote, regardless of blank lines between them. However, under the new renderer, those will be treated as two separate block quotes rather than being combined into one:

    > This and the below line would previously be rendered as a single contiguous block...
    
    > ...but today render as two separate blocks
    

    To get them to render as a single block, you now need a right angle bracket between the two lines:

    > This renders as a single contiguous block...
    >
    > ...fully compliant with the new CommonMark renderer.
    

    This rule was common enough to be included in the migration script, though. But, as your post wasn't automatically edited, what happened here is that there must have been something else that wasn't compliant that caused the automated script to back out. And, after looking at your post, I can see that it happens to be...

  • Multi-line code block within a block quote. Under the prior renderer, if you wanted a code block within a block quote, it was only necessary to preface the first line with a right angle bracket. However, under the new renderer, every line needs to be prefaced with right angle brackets:

    >     This would render as a single code block under the prior renderer, ...
        ...but wouldn't under the new renderer...
        ...because not every line is prefaced by a right angle bracket.
    

    The following works under the new renderer, however:

    >     This will render as a single code block in the new renderer, ...
    >     ...because every line is prefaced by a right angle bracket, ...
    >     ...which is now required.
    

In summary, your post wasn't compliant with the new renderer, and contained a problem that wasn't common enough to be included in the automatic migration script. This resulted in the old cached HTML from the previous renderer continuing to be served, which masked out the problems for a while, but as you just edited your post, the problems are now fully visible.

1
7

Yes, the migration to CommonMark did mess up that answer, because it does a couple of things that are not allowed in CommonMark. The culmination of those things likely prevented it from being detected by the automated scripts that attempted to edit old posts so they would render the same as before...

  1. CommonMark explicitly forbids using lazy continuation of block quotes if the formatting of the lazy-continued line would result in another block element being produced instead. In this case, the indentation would cause a code block, so the block quote cannot be continued lazily. You must include a > at the beginning of each line to make all the code a part of the block quote.
  2. CommonMark no longer allows blank lines in between > prefixed lines to continue a single block quote. Instead, a blank line between two of them will produce two separate block quotes.

These two things together present a confusing situation that is hard to catch automatically. You'll need to update the answer to use correct CommonMark formatting. As currently written, it is being rendered correctly per the CommonMark specifications.

4
  • 1
    The reason why it didn't edit the post was not because it was overlooked by the detector, but because it had consciously calculated that the rendered HTML from the automatic edit wouldn't match that of the previous edit (the script didn't contain every single rule difference, only the most common ones). Commented Sep 10, 2020 at 20:35
  • 1
    @Sonic Those are functionally equivalent statements. Not recognizing a particular situation would inherently cause the final renderings to not be the same. This is a tough case for an automated script to fix even if the specific rules were both included, because it combines two issues.
    – animuson StaffMod
    Commented Sep 10, 2020 at 20:43
  • 3
    @animuson, I think the nuance that Sonic was looking for is the difference between overlooking the post (with the implication conversion wasn't attempted) and backing out of the conversion because the look couldn't be preserved automatically. Commented Sep 11, 2020 at 12:03
  • Got it, thank you very much for the explanation! Follow-up question: How can I list all the questions and answers whose CommonMark rendering doesn't match the cached rendering? Commented Sep 12, 2020 at 19:28
4

Did the automated CommonMark migration mess up the formatting of this answer?

No

That answer's revision history shows no evidence of an automated "Commonmark migration" edit by the Community user, such as those found here.

Manual edits by the author after the switch to CommonMark caused the rendered HTML to be changed ("wrong"). But prior to those user edits, the cached HTML rendered by the pre-CommonMark parser was displayed.

So the automated CommonMark migration didn't mess anything up, but the switch to CommonMark, plus a subsequent edit of any kind, did.

This possibility was called out in We're switching to CommonMark :

Things might get funky when you're editing a post that renders differently with the new CommonMark renderer. Again, if we detected that a post would look differently when rendered with the new CommonMark renderer during the migration, we wouldn't save a new version of this post as part of the migration. This way, all posts continue to look the same when being viewed. However, once someone comes in and edits it, it will be rendered using the new CommonMark renderer and this might cause the post to look slightly different than what we had before. This will only be a small fraction of all of our posts, and of that small fraction a smaller fraction will actually be edited moving forward. However, it's important to keep in mind that editing old posts has a slight chance that you run into differences between our old and our new markdown renderers.

1
  • Good point, my mistake, I shouldn't have used the term "automated". Commented Sep 12, 2020 at 19:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .