Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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
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.
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.
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!