Bug 47990 - Ordered list numbering does not continue if code block is between numbered blocks
Summary: Ordered list numbering does not continue if code block is between numbered bl...
Alias: None
Product: Workbooks & Inspector
Classification: Xamarin
Component: Client: Cross Platform (Shared Code) ()
Version: master
Hardware: PC Windows
: Normal enhancement
Target Milestone: Future
Assignee: xamarininteractive
Depends on:
Reported: 2016-11-25 18:40 UTC by Michael Carter
Modified: 2017-01-12 16:08 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 47990 on Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.
Related Links:

Description Michael Carter 2016-11-25 18:40:25 UTC
In the sample workbooks, the following is not rendered as expected.

1. Get all the config out of the way

var webClient = new System.Net.WebClient();

1. We have to set up the 'callback' handler which is called when the network operation completes

var response1 = "";

1. *Then* we call the actual method - confusing huh? The code we just wrote above gets executed *after* this completes!

// this will be blank because the completed even won't have fired in most cases

The expected result is that you would see the number sequence continue 1, 2, 3. Instead it shows 1, 1, 1.

Note that MarkDown does specify that inner items should be indented in order for numbered lists to continue. However, when I tried to manually indent the code fences ```, an error was displayed that it was invalid. NOTE: indenting did render properly in a MarkDown editor (stackedit.com).

So it would be helpful to either add support for indented code fences, or add logic to handle code fences between numbered items so they are rendered properly.
Comment 3 Aaron Bockover [MSFT] 2017-01-12 00:37:36 UTC
Support for proper ordered list continuation and editable code cells in arbitrary block nesting is on our radar.

Due to limitations in the current editors we are leveraging, we have to "pre-parse" the workbook/markdown document and break it into cells. When editing, these cells effectively have their own isolated markdown context.

In the future we will have one primary document editor that retains full markdown context, and code blocks (indented or fenced) can be editable in place, regardless of block nesting.
Comment 4 Michael Carter 2017-01-12 16:08:16 UTC
Aaron. Thanks for the update. That makes perfect sense as to why it currently works that way.

I found a workaround for creating numbered text blocks for now.

You have to manually number each item, but you can't use 1. 2. 3. like you use with Markdown. The parser will reset each block back to 1.

I found that if you use something like:

1 - this is first item

2 - this is second item

3 - this is third item

It will render the blocks verbatim (no longer treats it as a numbered item). I tried using the closing parenthesis like 1) 2) 3) and the parser, oddly enough, renumbered the first two as 1. 1. and left the third as 3)

So it looks like as long as you leave a space after the number, the parser will not treat it as a numbered list item.

Anyway, my workaround is fine for now. Looking forward to the updated parser. Keep up the great work!