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>
|
|
|
|
|
2017-03-20 18:54:00 +01:00
|
|
|
Removes trailing whitespace from code blocks that cause horizontal scrolling
|
|
|
|
>>> import markdown
|
|
|
|
>>> text = '''
|
|
|
|
... A paragraph before a fenced code block:
|
|
|
|
...
|
|
|
|
... ~~~
|
|
|
|
... Fenced code block \t\t\t\t\t\t\t
|
|
|
|
... ~~~
|
|
|
|
... '''
|
|
|
|
>>> 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>
|
|
|
|
|
2012-11-19 17:55:28 +01:00
|
|
|
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
|
2017-03-20 16:56:39 +01:00
|
|
|
import subprocess
|
2012-11-19 17:55:28 +01:00
|
|
|
import markdown
|
2017-03-20 16:56:39 +01:00
|
|
|
import six
|
|
|
|
from django.utils.html import escape
|
2016-10-16 08:36:31 +02:00
|
|
|
from markdown.extensions.codehilite import CodeHilite, CodeHiliteExtension
|
2017-03-20 16:56:39 +01:00
|
|
|
from zerver.lib.str_utils import force_bytes
|
|
|
|
from zerver.lib.tex import render_tex
|
2016-12-05 07:05:33 +01:00
|
|
|
from typing import Any, Dict, Iterable, List, MutableSequence, Optional, Tuple, Union, Text
|
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)
|
|
|
|
|
|
|
|
|
2017-03-20 18:54:00 +01:00
|
|
|
CODE_WRAP = u'<pre><code%s>%s\n</code></pre>'
|
2016-06-16 13:24:52 +02:00
|
|
|
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'
|
2016-12-11 14:30:45 +01:00
|
|
|
if 'normalize_whitespace' in md.preprocessors
|
|
|
|
else '_begin')
|
2013-04-04 23:14:33 +02:00
|
|
|
|
2012-11-19 17:55:28 +01:00
|
|
|
md.preprocessors.add('fenced_code_block',
|
2016-11-30 14:17:35 +01:00
|
|
|
FencedBlockPreprocessor(md),
|
|
|
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (Iterable[Text]) -> List[Text]
|
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-12-05 07:05:33 +01:00
|
|
|
output = [] # type: List[Text]
|
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):
|
2016-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> None
|
2016-06-16 18:04:53 +02:00
|
|
|
raise NotImplementedError()
|
2016-11-29 07:22:02 +01:00
|
|
|
|
2016-06-16 18:04:53 +02:00
|
|
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (MutableSequence[Text], Text) -> 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-12-05 07:05:33 +01:00
|
|
|
# type: (MutableSequence[Text]) -> None
|
2016-05-17 12:49:38 +02:00
|
|
|
self.output = output
|
|
|
|
|
|
|
|
def handle_line(self, line):
|
2016-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> 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-12-05 07:05:33 +01:00
|
|
|
# type: (MutableSequence[Text], Text, Text) -> 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)
|
2017-03-20 16:56:39 +01:00
|
|
|
elif lang in ('math', 'tex', 'latex'):
|
|
|
|
return TexHandler(output, fence)
|
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
|
|
|
else:
|
|
|
|
return CodeHandler(output, fence, lang)
|
|
|
|
|
2017-03-20 16:56:39 +01:00
|
|
|
class CodeHandler(BaseHandler):
|
|
|
|
def __init__(self, output, fence, lang):
|
|
|
|
# type: (MutableSequence[Text], Text, Text) -> None
|
|
|
|
self.output = output
|
|
|
|
self.fence = fence
|
|
|
|
self.lang = lang
|
|
|
|
self.lines = [] # type: List[Text]
|
|
|
|
|
|
|
|
def handle_line(self, line):
|
|
|
|
# type: (Text) -> None
|
|
|
|
if line.rstrip() == self.fence:
|
|
|
|
self.done()
|
|
|
|
else:
|
2017-03-20 18:54:00 +01:00
|
|
|
self.lines.append(line.rstrip())
|
2017-03-20 16:56:39 +01:00
|
|
|
|
|
|
|
def done(self):
|
|
|
|
# type: () -> None
|
|
|
|
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()
|
|
|
|
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (MutableSequence[Text], Text) -> 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-12-05 07:05:33 +01:00
|
|
|
self.lines = [] # type: List[Text]
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> 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()
|
|
|
|
|
2017-03-20 16:56:39 +01:00
|
|
|
class TexHandler(BaseHandler):
|
|
|
|
def __init__(self, output, fence):
|
|
|
|
# type: (MutableSequence[Text], Text) -> 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-12-05 07:05:33 +01:00
|
|
|
self.lines = [] # type: List[Text]
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> 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:
|
2017-03-20 16:56:39 +01:00
|
|
|
check_for_new_fence(self.lines, line)
|
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 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)
|
2017-03-20 16:56:39 +01:00
|
|
|
text = processor.format_tex(text)
|
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 = 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-12-05 07:05:33 +01:00
|
|
|
# type: (Text, Text) -> Text
|
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,
|
2016-12-11 14:30:45 +01:00
|
|
|
linenums=self.codehilite_conf['linenums'][0],
|
|
|
|
guess_lang=self.codehilite_conf['guess_lang'][0],
|
|
|
|
css_class=self.codehilite_conf['css_class'][0],
|
|
|
|
style=self.codehilite_conf['pygments_style'][0],
|
|
|
|
use_pygments=self.codehilite_conf['use_pygments'][0],
|
|
|
|
lang=(lang or None),
|
|
|
|
noclasses=self.codehilite_conf['noclasses'][0])
|
2013-11-20 19:11:07 +01:00
|
|
|
|
|
|
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> Text
|
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)
|
|
|
|
|
2017-03-20 16:56:39 +01:00
|
|
|
def format_tex(self, text):
|
|
|
|
# type: (Text) -> Text
|
|
|
|
paragraphs = text.split("\n\n")
|
|
|
|
tex_paragraphs = []
|
|
|
|
for paragraph in paragraphs:
|
|
|
|
html = render_tex(paragraph, is_inline=False)
|
|
|
|
if html is not None:
|
|
|
|
tex_paragraphs.append(html)
|
|
|
|
else:
|
|
|
|
tex_paragraphs.append('<span class="tex-error">' +
|
|
|
|
escape(paragraph) + '</span>')
|
|
|
|
return "\n\n".join(tex_paragraphs)
|
|
|
|
|
2013-11-20 21:03:57 +01:00
|
|
|
def placeholder(self, code):
|
2016-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> Text
|
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-12-05 07:05:33 +01:00
|
|
|
# type: (Text) -> Text
|
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
|
|
|
|
|
|
|
|
|
2016-10-14 05:23:15 +02:00
|
|
|
def makeExtension(*args, **kwargs):
|
2016-12-05 07:05:33 +01:00
|
|
|
# type: (*Any, **Union[bool, None, Text]) -> FencedCodeExtension
|
2016-10-14 05:23:15 +02:00
|
|
|
return FencedCodeExtension(*args, **kwargs)
|
2012-11-19 17:55:28 +01:00
|
|
|
|
|
|
|
if __name__ == "__main__":
|
|
|
|
import doctest
|
|
|
|
doctest.testmod()
|