2016-04-07 15:03:22 +02:00
|
|
|
#!/usr/bin/env python
|
2012-11-19 17:55:28 +01:00
|
|
|
|
|
|
|
"""
|
|
|
|
Fenced Code Extension for Python Markdown
|
|
|
|
=========================================
|
|
|
|
|
|
|
|
This extension adds Fenced Code Blocks to Python-Markdown.
|
|
|
|
|
|
|
|
>>> import markdown
|
|
|
|
>>> text = '''
|
|
|
|
... A paragraph before a fenced code block:
|
|
|
|
...
|
|
|
|
... ~~~
|
|
|
|
... Fenced code block
|
|
|
|
... ~~~
|
|
|
|
... '''
|
|
|
|
>>> html = markdown.markdown(text, extensions=['fenced_code'])
|
|
|
|
>>> print html
|
|
|
|
<p>A paragraph before a fenced code block:</p>
|
|
|
|
<pre><code>Fenced code block
|
|
|
|
</code></pre>
|
|
|
|
|
|
|
|
Works with safe_mode also (we check this because we are using the HtmlStash):
|
|
|
|
|
|
|
|
>>> print markdown.markdown(text, extensions=['fenced_code'], safe_mode='replace')
|
|
|
|
<p>A paragraph before a fenced code block:</p>
|
|
|
|
<pre><code>Fenced code block
|
|
|
|
</code></pre>
|
|
|
|
|
|
|
|
Include tilde's in a code block and wrap with blank lines:
|
|
|
|
|
|
|
|
>>> text = '''
|
|
|
|
... ~~~~~~~~
|
|
|
|
...
|
|
|
|
... ~~~~
|
|
|
|
... ~~~~~~~~'''
|
|
|
|
>>> print markdown.markdown(text, extensions=['fenced_code'])
|
|
|
|
<pre><code>
|
|
|
|
~~~~
|
|
|
|
</code></pre>
|
|
|
|
|
|
|
|
Language tags:
|
|
|
|
|
|
|
|
>>> text = '''
|
|
|
|
... ~~~~{.python}
|
|
|
|
... # Some python code
|
|
|
|
... ~~~~'''
|
|
|
|
>>> print markdown.markdown(text, extensions=['fenced_code'])
|
|
|
|
<pre><code class="python"># Some python code
|
|
|
|
</code></pre>
|
|
|
|
|
|
|
|
Copyright 2007-2008 [Waylan Limberg](http://achinghead.com/).
|
|
|
|
|
|
|
|
Project website: <http://packages.python.org/Markdown/extensions/fenced_code_blocks.html>
|
|
|
|
Contact: markdown@freewisdom.org
|
|
|
|
|
|
|
|
License: BSD (see ../docs/LICENSE for details)
|
|
|
|
|
|
|
|
Dependencies:
|
|
|
|
* [Python 2.4+](http://python.org)
|
|
|
|
* [Markdown 2.0+](http://packages.python.org/Markdown/)
|
|
|
|
* [Pygments (optional)](http://pygments.org)
|
|
|
|
|
|
|
|
"""
|
|
|
|
|
|
|
|
import re
|
|
|
|
import markdown
|
2013-07-29 23:03:31 +02:00
|
|
|
from zerver.lib.bugdown.codehilite import CodeHilite, CodeHiliteExtension
|
2016-06-16 13:24:52 +02:00
|
|
|
from six import text_type
|
2016-06-16 14:46:59 +02:00
|
|
|
from typing import Any, Dict, Iterable, List, MutableSequence, Optional, Tuple, Union
|
2012-11-19 17:55:28 +01:00
|
|
|
|
|
|
|
# Global vars
|
2016-06-16 13:24:52 +02:00
|
|
|
FENCE_RE = re.compile(u"""
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
# ~~~ or ```
|
|
|
|
(?P<fence>
|
|
|
|
^(?:~{3,}|`{3,})
|
2012-11-19 17:55:28 +01:00
|
|
|
)
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
|
|
|
[ ]* # spaces
|
|
|
|
|
|
|
|
(
|
2016-06-16 13:24:52 +02:00
|
|
|
\\{?\\.?
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
(?P<lang>
|
|
|
|
[a-zA-Z0-9_+-]*
|
|
|
|
) # "py" or "javascript"
|
2016-06-16 13:24:52 +02:00
|
|
|
\\}?
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
) # language, like ".py" or "{javascript}"
|
2014-03-06 00:05:49 +01:00
|
|
|
[ ]* # spaces
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
$
|
|
|
|
""", re.VERBOSE)
|
|
|
|
|
|
|
|
|
2016-06-16 13:24:52 +02:00
|
|
|
CODE_WRAP = u'<pre><code%s>%s</code></pre>'
|
|
|
|
LANG_TAG = u' class="%s"'
|
2012-11-19 17:55:28 +01:00
|
|
|
|
|
|
|
class FencedCodeExtension(markdown.Extension):
|
|
|
|
|
|
|
|
def extendMarkdown(self, md, md_globals):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (markdown.Markdown, Dict[str, Any]) -> None
|
2012-11-19 17:55:28 +01:00
|
|
|
""" Add FencedBlockPreprocessor to the Markdown instance. """
|
|
|
|
md.registerExtension(self)
|
|
|
|
|
2013-04-04 23:14:33 +02:00
|
|
|
# Newer versions of Python-Markdown (starting at 2.3?) have
|
|
|
|
# a normalize_whitespace preprocessor that needs to go first.
|
|
|
|
position = ('>normalize_whitespace'
|
|
|
|
if 'normalize_whitespace' in md.preprocessors
|
|
|
|
else '_begin')
|
|
|
|
|
2012-11-19 17:55:28 +01:00
|
|
|
md.preprocessors.add('fenced_code_block',
|
|
|
|
FencedBlockPreprocessor(md),
|
2013-04-04 23:14:33 +02:00
|
|
|
position)
|
2012-11-19 17:55:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
class FencedBlockPreprocessor(markdown.preprocessors.Preprocessor):
|
|
|
|
|
|
|
|
def __init__(self, md):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (markdown.Markdown) -> None
|
2012-11-19 17:55:28 +01:00
|
|
|
markdown.preprocessors.Preprocessor.__init__(self, md)
|
|
|
|
|
|
|
|
self.checked_for_codehilite = False
|
2016-06-16 13:24:52 +02:00
|
|
|
self.codehilite_conf = {} # type: Dict[str, List[Any]]
|
2012-11-19 17:55:28 +01:00
|
|
|
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
def run(self, lines):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (Iterable[text_type]) -> List[text_type]
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
""" Match and store Fenced Code Blocks in the HtmlStash. """
|
|
|
|
|
2016-06-16 14:46:59 +02:00
|
|
|
output = [] # type: List[text_type]
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
2016-06-16 18:04:53 +02:00
|
|
|
class BaseHandler(object):
|
|
|
|
def handle_line(self, line):
|
|
|
|
# type: (text_type) -> None
|
|
|
|
raise NotImplementedError()
|
|
|
|
def done(self):
|
|
|
|
# type: () -> None
|
|
|
|
raise NotImplementedError()
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
|
|
|
processor = self
|
2016-06-16 18:04:53 +02:00
|
|
|
handlers = [] # type: List[BaseHandler]
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
|
|
|
def push(handler):
|
2016-06-16 18:04:53 +02:00
|
|
|
# type: (BaseHandler) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
handlers.append(handler)
|
|
|
|
|
|
|
|
def pop():
|
2016-06-16 18:04:53 +02:00
|
|
|
# type: () -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
handlers.pop()
|
|
|
|
|
|
|
|
def check_for_new_fence(output, line):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (MutableSequence[text_type], text_type) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
m = FENCE_RE.match(line)
|
|
|
|
if m:
|
|
|
|
fence = m.group('fence')
|
|
|
|
lang = m.group('lang')
|
|
|
|
handler = generic_handler(output, fence, lang)
|
|
|
|
push(handler)
|
|
|
|
else:
|
|
|
|
output.append(line)
|
|
|
|
|
2016-06-16 18:04:53 +02:00
|
|
|
class OuterHandler(BaseHandler):
|
2016-05-17 12:49:38 +02:00
|
|
|
def __init__(self, output):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (MutableSequence[text_type]) -> None
|
2016-05-17 12:49:38 +02:00
|
|
|
self.output = output
|
|
|
|
|
|
|
|
def handle_line(self, line):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> None
|
2016-05-17 12:49:38 +02:00
|
|
|
check_for_new_fence(self.output, line)
|
|
|
|
|
|
|
|
def done(self):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: () -> None
|
2016-05-17 12:49:38 +02:00
|
|
|
pop()
|
|
|
|
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
def generic_handler(output, fence, lang):
|
2016-06-16 18:04:53 +02:00
|
|
|
# type: (MutableSequence[text_type], text_type, text_type) -> BaseHandler
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
if lang in ('quote', 'quoted'):
|
|
|
|
return QuoteHandler(output, fence)
|
|
|
|
else:
|
|
|
|
return CodeHandler(output, fence, lang)
|
|
|
|
|
2016-06-16 18:04:53 +02:00
|
|
|
class QuoteHandler(BaseHandler):
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
def __init__(self, output, fence):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (MutableSequence[text_type], text_type) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
self.output = output
|
|
|
|
self.fence = fence
|
2016-06-16 14:46:59 +02:00
|
|
|
self.lines = [] # type: List[text_type]
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
|
|
|
def handle_line(self, line):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
if line.rstrip() == self.fence:
|
|
|
|
self.done()
|
|
|
|
else:
|
|
|
|
check_for_new_fence(self.lines, line)
|
|
|
|
|
|
|
|
def done(self):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: () -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
text = '\n'.join(self.lines)
|
|
|
|
text = processor.format_quote(text)
|
|
|
|
processed_lines = text.split('\n')
|
|
|
|
self.output.append('')
|
|
|
|
self.output.extend(processed_lines)
|
|
|
|
self.output.append('')
|
|
|
|
pop()
|
|
|
|
|
2016-06-16 18:04:53 +02:00
|
|
|
class CodeHandler(BaseHandler):
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
def __init__(self, output, fence, lang):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (MutableSequence[text_type], text_type, text_type) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
self.output = output
|
|
|
|
self.fence = fence
|
|
|
|
self.lang = lang
|
2016-06-16 14:46:59 +02:00
|
|
|
self.lines = [] # type: List[text_type]
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
|
|
|
|
def handle_line(self, line):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
if line.rstrip() == self.fence:
|
|
|
|
self.done()
|
|
|
|
else:
|
|
|
|
self.lines.append(line)
|
|
|
|
|
|
|
|
def done(self):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: () -> None
|
Support arbitrarily nested fenced quote/code blocks.
Now we can nest fenced code/quote blocks inside of quote
blocks down to arbitrary depths. Code blocks are always leafs.
Fenced blocks start with at least three tildes or backticks,
and the clump of punctuation then becomes the terminator for
the block. If the user ends their message without terminators,
all blocks are automatically closed.
When inside a quote block, you can start another fenced block
with any header that doesn't match the end-string of the outer
block. (If you don't want to specify a language, then you
can change the number of backticks/tildes to avoid amiguity.)
Most of the heavy lifting happens in FencedBlockPreprocessor.run().
The parser works by pushing handlers on to a stack and popping
them off when the ends of blocks are encountered. Parents communicate
with their children by passing in a simple Python list of strings
for the child to append to. Handlers also maintain their own
lists for their own content, and when their done() method is called,
they render their data as needed.
The handlers are objects returned by functions, and the handler
functions close on variables push, pop, and processor. The closure
style here makes the handlers pretty tightly coupled to the outer
run() method. If we wanted to move to a class-based style, the
tradeoff would be that the class instances would have to marshall
push/pop/processor etc., but we could test the components more
easily in isolation.
Dealing with blank lines is very fiddly inside of bugdown.
The new functionality here is captured in the test
BugdownTest.test_complexly_nested_quote().
(imported from commit 53886c8de74bdf2bbd3cef8be9de25f05bddb93c)
2013-11-20 23:25:48 +01:00
|
|
|
text = '\n'.join(self.lines)
|
|
|
|
text = processor.format_code(self.lang, text)
|
|
|
|
text = processor.placeholder(text)
|
|
|
|
processed_lines = text.split('\n')
|
|
|
|
self.output.append('')
|
|
|
|
self.output.extend(processed_lines)
|
|
|
|
self.output.append('')
|
|
|
|
pop()
|
|
|
|
|
|
|
|
handler = OuterHandler(output)
|
|
|
|
push(handler)
|
|
|
|
|
|
|
|
for line in lines:
|
|
|
|
handlers[-1].handle_line(line)
|
|
|
|
|
|
|
|
while handlers:
|
|
|
|
handlers[-1].done()
|
|
|
|
|
|
|
|
# This fiddly handling of new lines at the end of our output was done to make
|
|
|
|
# existing tests pass. Bugdown is just kind of funny when it comes to new lines,
|
|
|
|
# but we could probably remove this hack.
|
|
|
|
if len(output) > 2 and output[-2] != '':
|
|
|
|
output.append('')
|
|
|
|
return output
|
|
|
|
|
2013-11-20 19:48:44 +01:00
|
|
|
def format_code(self, lang, text):
|
2016-06-16 13:24:52 +02:00
|
|
|
# type: (text_type, text_type) -> text_type
|
2013-11-20 19:48:44 +01:00
|
|
|
if lang:
|
|
|
|
langclass = LANG_TAG % (lang,)
|
2016-06-16 13:24:52 +02:00
|
|
|
else:
|
|
|
|
langclass = ''
|
2013-11-20 19:48:44 +01:00
|
|
|
|
2013-11-20 19:11:07 +01:00
|
|
|
# Check for code hilite extension
|
|
|
|
if not self.checked_for_codehilite:
|
|
|
|
for ext in self.markdown.registeredExtensions:
|
|
|
|
if isinstance(ext, CodeHiliteExtension):
|
|
|
|
self.codehilite_conf = ext.config
|
|
|
|
break
|
|
|
|
|
|
|
|
self.checked_for_codehilite = True
|
|
|
|
|
|
|
|
# If config is not empty, then the codehighlite extension
|
|
|
|
# is enabled, so we call it to highlite the code
|
|
|
|
if self.codehilite_conf:
|
|
|
|
highliter = CodeHilite(text,
|
|
|
|
force_linenos=self.codehilite_conf['force_linenos'][0],
|
|
|
|
guess_lang=self.codehilite_conf['guess_lang'][0],
|
|
|
|
css_class=self.codehilite_conf['css_class'][0],
|
|
|
|
style=self.codehilite_conf['pygments_style'][0],
|
|
|
|
lang=(lang or None),
|
|
|
|
noclasses=self.codehilite_conf['noclasses'][0])
|
|
|
|
|
|
|
|
code = highliter.hilite()
|
|
|
|
else:
|
|
|
|
code = CODE_WRAP % (langclass, self._escape(text))
|
|
|
|
|
|
|
|
return code
|
2013-01-29 16:14:30 +01:00
|
|
|
|
2013-11-20 19:29:54 +01:00
|
|
|
def format_quote(self, text):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> text_type
|
2013-11-20 19:29:54 +01:00
|
|
|
paragraphs = text.split("\n\n")
|
|
|
|
quoted_paragraphs = []
|
|
|
|
for paragraph in paragraphs:
|
|
|
|
lines = paragraph.split("\n")
|
|
|
|
quoted_paragraphs.append("\n".join("> " + line for line in lines if line != ''))
|
|
|
|
return "\n\n".join(quoted_paragraphs)
|
|
|
|
|
2013-11-20 21:03:57 +01:00
|
|
|
def placeholder(self, code):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> text_type
|
2013-11-20 21:03:57 +01:00
|
|
|
return self.markdown.htmlStash.store(code, safe=True)
|
|
|
|
|
2012-11-19 17:55:28 +01:00
|
|
|
def _escape(self, txt):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (text_type) -> text_type
|
2012-11-19 17:55:28 +01:00
|
|
|
""" basic html escaping """
|
|
|
|
txt = txt.replace('&', '&')
|
|
|
|
txt = txt.replace('<', '<')
|
|
|
|
txt = txt.replace('>', '>')
|
|
|
|
txt = txt.replace('"', '"')
|
|
|
|
return txt
|
|
|
|
|
|
|
|
|
|
|
|
def makeExtension(configs=None):
|
2016-06-16 14:46:59 +02:00
|
|
|
# type: (Optional[List[Tuple[str, Union[bool, None, text_type]]]]) -> FencedCodeExtension
|
2012-11-19 17:55:28 +01:00
|
|
|
return FencedCodeExtension(configs=configs)
|
|
|
|
|
|
|
|
|
|
|
|
if __name__ == "__main__":
|
|
|
|
import doctest
|
|
|
|
doctest.testmod()
|