Markdown code block syntax doesn't convert to roff's .EX/.EE syntax

[yumetodo]

Look at man 3 printf

.EX
printf("%*d", width, num);
.EE

To markup example code, they use roff's .EX/.EE syntax

Now I tried to convert
https://github.com/MicrosoftDocs/cpp-docs/blob/master/docs/c-runtime-library/reference/rand.md

However, ronn-ng didn't use this syntax.

For additional compatibility information, see [Compatibility](../../c-runtime-library/compatibility.md).

## Example

```C
// crt_rand.c
// This program seeds the random-number generator
// with the time, then exercises the rand function.
//

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

void SimpleRandDemo( int n )
{
   // Print n random numbers.
   int i;
   for( i = 0; i < n; i++ )
      printf( "  %6d\n", rand() );
}

void RangedRandDemo( int range_min, int range_max, int n )
{
   // Generate random numbers in the half-closed interval
   // [range_min, range_max). In other words,
   // range_min <= random number < range_max
   int i;
   for ( i = 0; i < n; i++ )
   {
      int u = (double)rand() / (RAND_MAX + 1) * (range_max - range_min)
            + range_min;
      printf( "  %6d\n", u);
   }
}

int main( void )
{
   // Seed the random-number generator with the current time so that
   // the numbers will be different every time we run.
   srand( (unsigned)time( NULL ) );

   SimpleRandDemo( 10 );
   printf("\n");
   RangedRandDemo( -100, 100, 10 );
}
```

For more information, see Compatibility \fI\.\./\.\./c\-runtime\-library/compatibility\.md\fR\.
.SH "Example"
```C // crt_rand_s\.c // This program illustrates how to generate random // integer or floating point numbers in a specified range\.
.P
// Remembering to define _CRT_RAND_S prior // to inclusion statement\. #define _CRT_RAND_S#include
.P
int main( void ) { int i; unsigned int number; double max = 100\.0; errno_t err;
.IP "" 4
.nf
// Display 10 random integers in the range [ 1,10 ]\.
for( i = 0; i < 10;i++ )
{
    err = rand_s( &number );
    if (err != 0)
    {
        printf_s("The rand_s function failed!\en");
    }
    printf_s( "  %u\en", (unsigned int) ((double)number /
                   ((double) UINT_MAX + 1 ) * 10\.0) + 1);
}

printf_s("\en");

// Display 10 random doubles in [0, max)\.
for (i = 0; i < 10;i++ )
{
    err = rand_s( &number );
    if (err != 0)
    {
        printf_s("The rand_s function failed!\en");
    }
    printf_s( "  %g\en", (double) number /
                      ((double) UINT_MAX + 1) * max );
} } ```
.fi
.IP "" 0

[apjanke]

This sure looks like a bug in Ronn-NG, and I think it might be caused by our current issue with "fenced code block" support, which is addressed by #53. Looking at the output you've posted here, it looks like Markdown fenced code blocks (which are technically an extension, not in the base Markdown syntax) are not being translated to HTML, so the HTML-to-roff processor can't format them as .EX/.EE roff blocks.

Once I get the tests cleaned up on that PR #53 (hopefully within the week), I'll see if that fixes this problem, too.

Thanks for the bug report!

[yumetodo]

which are technically an extension, not in the base Markdown syntax

Fenced code blocks are defined in CommonMark Spec, AFAIK.
https://spec.commonmark.org/0.29/#fenced-code-blocks

[apjanke]

I (and many others) consider CommonMark itself to be an extension or variant, despite the name "Common" and their original intended use of the term "standard". IMHO, vanilla Markdown is Gruber's original spec. CommonMark aspires to be a "standard", but it ain't there yet, IMHO, and GitHub Flavored Markdown is currently a lot closer to that goal.

If there's interest among Ronn-NG's users, and an easy way of implementing it here, I'd be happy to add support for CommonMark as an optional dialect supported by Ronn-NG.

[apjanke]

This PR fixed the basic problem with the "```" fenced code blocks not being interpreted: #53.

But it's still not using .EX/.EE. It's just using .nf/.fi, I think, treating it like <pre> text instead of specifically a code example.

I think you're right that <code> should be using .EX/.EE.

This is going to take a little more research and engineering to fix. I'm still slating it for 0.10.0, and should have some time to work on it over this weekend.

[apjanke]

Okay, this is gonna take some nontrivial reworking of the processing code. I'm bumping this out to the 0.11.0 release so we can get 0.10.0 out the door with some bugfixes users are asking for.

ETA on this is likely a few weeks off; sorry.