1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
//! Painted fenced blocks for `markdown`.
//!
//! ```ignore
//! markdown::set_block_renderer(cx, blocks::render); // once, at boot
//! ```
//!
//! A fence already round trips byte for byte, already holds a caret, and
//! already degrades to its own source where nothing paints it — so a block of
//! an app's own is a renderer over ` ```chart ` rather than a new
//! `markdown::BlockKind`. This crate is one answer to that seam; an app with
//! its own block writes the same function and never depends on this.
//!
//! It is a peer crate rather than a feature on `markdown` for the reason
//! `syntax` is: cargo features are additive across the whole graph, so a
//! `markdown/mermaid` any dependency turned on is one no consumer can turn back
//! off, and a block carrying a parser would break a target nobody asked about.
//! A crate you do not name costs nothing.
//!
//! `markdown` is not a dependency here. A renderer is a fence tag and a string
//! in, an element out, which needs no document model — the consumer's call to
//! `set_block_renderer` is what pins the signature.
use ;
/// Paint the block a fence names, or `None` to leave it to the ordinary code
/// block.
///
/// One answer for a tag no enabled block claims, a block turned off at compile
/// time, and a block that read the source and declined.
/// The fence tags the enabled blocks answer to, for a language picker that
/// would otherwise offer a block this build cannot paint.