These result from something like
@racket[(x y)]
being treated by Scribble as multiple RktXXX items rather than one. As
a result the Markdown emitted was:
`(``x`` ``y``)`
But obviously instead we want:
`(x y)`
Kludgosity alert: Although it would probably be more-correct to
consolidate the RktXXX items at the Scribble structure level, I don't
easily see how. `@racket` is baking in the concept of Racket
lexing (classifying text as various kinds of Racket elements). This is
handy when the render will be HTML or Latek, and is benignly N/A when
it will be plain text. But it's a bit square-peg/round-hole when the
render will be Markdown. Rather than attempt to "un-lex" the Scribble
structures (I'm having trouble seeing how), I'm handling it
"after-the-fact" -- adjusting the generated Markdown text.
If anyone thinks the preceding is an elaborate rationalization for an
ugly kludge, I wouldn't argue, but I would need some help
understanding the preferable way to go about it.
Unlike plain `racketblock`, `examples` and `interaction` are
"nested". As a result we emitted bad Markdown like:
```racket
Examples:
```racket
some-code
```
```
Markdown code blocks can't nest, so this needs to be:
```racket
Examples:
some-code
```
Also: Updated the unit test with examples of `examples` and
`interaction`.
Had been specifying Scheme lexer for code blocks, while waiting for
new Racket lexer to wend its way from Pygments to Pygments.rb to
Linguist to GitHub.
That day is almost here: Linguist will soon update and deploy to
GitHub. And Racket 5.3.2 is about to release. As a result, I think
this is the correct time to switch to the Racket lexer: It should be
live on GitHub by the time people are using Racket 5.3.2.
/cc @rmculpepper -- I think this commit should go into the 5.3.2
release.
More precisely, do this for nested flows with the "refcontent" style.
For instance this Scribble:
@margin-note{Note: This is a note. Let's make it long enough that the
markdown output will have to line-wrap, to make sure the > mark starts
each line properly.}
Will render as this Markdown:
> Note: This is a note. Let's make it long enough that the markdown output
> will have to line-wrap, to make sure the > mark starts each line
> properly.
A site like GitHub.com will render this in a block-quote style
suitable for notes:
> Note: This is a note. Let's make it long enough that the markdown output
> will have to line-wrap, to make sure the > mark starts each line
> properly.
Render Scribble like
@hyperlink["url" "content"]
as Markdown like
[content](url)
Note that this only works for `@hyperlink`. The motivation is to
preserve content the author has explicitly written. (Previously,
`markdown-render.rkt` was discarding this; `text-render.rkt` still
does so.)
This does _not_ attempt to handle everything that `html-render.rkt`
would automatically generate and render as `<a>`. It simply can't --
things like hotlinked Racket keywords in code blocks simply won't work
in Markdown.
Uses "Github flavored markdown". Specifically, code blocks are opened
using ```scheme so that Github will lex and format them as Scheme code
rather than generic monospace.
Note: I would have used ```racket, but we are still waiting for the
pygments.rb project to pull again from pygments-main -- to which I
contributed a Racket lexer back in August. After pygments.rb pulls,
can update this to use ```racket instead.
