python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] Oddity, blockquote?

[Dave P. <dav...@gm...>]

Apologies for the noise.

Tested in plain html - no line separation in <blockquote>

regards

On 26 August 2014 08:57, Dave Pawson <dav...@gm...> wrote:
> Input
>
> Note variance!
>
>>Their wand|'ring course|, now high|, now low|, then hid
>>Progress|ive, ret|rograde|, or stand|ing still
>
>
> Output
>
> <blockquote>
> <p>Their wand|'ring course|, now high|, now low|, then hid
> Progress|ive, ret|rograde|, or stand|ing still</p>
> </blockquote>
>
> No para break at the end of line?
>
> Any suggestions please - Other blockquotes in the same document are
> broken by p elements?
>
> regards
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

[Python-markdown-discuss] Oddity, blockquote?

[Dave P. <dav...@gm...>]

Input

Note variance!

>Their wand|'ring course|, now high|, now low|, then hid
>Progress|ive, ret|rograde|, or stand|ing still


Output

<blockquote>
<p>Their wand|'ring course|, now high|, now low|, then hid
Progress|ive, ret|rograde|, or stand|ing still</p>
</blockquote>

No para break at the end of line?

Any suggestions please - Other blockquotes in the same document are
broken by p elements?

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Re: [Python-markdown-discuss] Ideas for future development.

[Dave P. <dav...@gm...>]

On 26 August 2014 00:59, Waylan Limberg <way...@ic...> wrote:
> Dave,
>
> I assume you are referring to access to the parse tree from which you can
> render your own output.

Not as I saw it? I wanted to isolate the tokens sought by the parse,
with the possibility of adding new ones?


> I just can't see maintaining the
> existing API and moving to such a different way of parsing Markdown text. I
> think there is plenty of room for both implementations to thrive.

My issue with that is the constraints of being limited to the original
token set?

>
> That said, while Python-Markdown doesn't technically generate a parse tree -
> it does create the entire document as an ElementTree, and the serializer can
> be swapped out for your own - so you could write your own serializer which
> output XML if you desired.

Thanks, I hadn't thought of that aspect.

 Of course, you would then have to work out how to
> handle the Postprocessors that run after the serializer - but it's not
> impossible. See this [test][2] which demonstrates how to swap out the
> serializer.
>
> [1]: https://github.com/lepture/mistune
> [2]:
> https://github.com/waylan/Python-Markdown/blob/master/tests/test_apis.py#L38
> 6


Thanks for the links.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

[Python-markdown-discuss] Proposals now on Github

[Waylan L. <way...@ic...>]

The other day I posted a few proposals here on the list. However, as I'm
getting very little feedback and I know very few people actually subscribe
to this list, I've also posted the question to Github as issues. A lot more
people have accounts there, and with a smaller barrier to comment, I hope
for some more feedback. Of course, you can respond here on the list if you
desire.

 

Also, I posted a third proposal. So we have.

 

Should we drop support for "extname(config=option)"?:
https://github.com/waylan/Python-Markdown/issues/335

Should we deprecate mdx_* extension names?:
https://github.com/waylan/Python-Markdown/issues/336

Should we deprecate "safe_mode"?:
https://github.com/waylan/Python-Markdown/issues/337

Re: [Python-markdown-discuss] Ideas for future development.

[Waylan L. <way...@ic...>]

Dave,

I assume you are referring to access to the parse tree from which you can
render your own output. I know a few Markdown parsers that do this. The most
notably being Pandoc which outputs to a wide variety of formats
(unfortunately, Pandoc is not a python library although someone may have
written a python library that wraps Pandoc's command line interface -- which
admittedly does not give you access to the parse tree). There are a few C
libraries out there that either have a Python wrapper or can easily be
wrapped in Python that offer access to their parse tree (sorry I forget
which ones). And most recently, [Mistune][1] was created, which is a Python
port of the JavaScript Marked library. I haven't taken a real close look at
Mistune, but **if** it is a good port of Marked then I would say that it is
exactly what I would do if Python-Markdown's existing code, user base, and
extension API didn't already exist. I just can't see maintaining the
existing API and moving to such a different way of parsing Markdown text. I
think there is plenty of room for both implementations to thrive.

That said, while Python-Markdown doesn't technically generate a parse tree -
it does create the entire document as an ElementTree, and the serializer can
be swapped out for your own - so you could write your own serializer which
output XML if you desired. Of course, you would then have to work out how to
handle the Postprocessors that run after the serializer - but it's not
impossible. See this [test][2] which demonstrates how to swap out the
serializer.

[1]: https://github.com/lepture/mistune
[2]:
https://github.com/waylan/Python-Markdown/blob/master/tests/test_apis.py#L38
6

-----Original Message-----
From: Dave Pawson [mailto:dav...@gm...] 
Sent: Sunday, August 24, 2014 2:09 AM
To: Waylan Limberg; PythonMD list
Subject: [Python-markdown-discuss] Ideas for future development.

Very personal one.
I've an XML background. I can do things with XML I can't with plain text.

Idea for future development.

Isolate the mapping of input markup to output syntax.
Possibly isolating block and inlines.

That would allow replacement of html with XML.
(Ideally allowing extensions to use this form)

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

----------------------------------------------------------------------------
--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Python-markdown-discuss mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

[Python-markdown-discuss] Ideas for future development.

[Dave P. <dav...@gm...>]

Very personal one.
I've an XML background. I can do things with XML I can't with plain text.

Idea for future development.

Isolate the mapping of input markup to output syntax.
Possibly isolating block and inlines.

That would allow replacement of html with XML.
(Ideally allowing extensions to use this form)

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Re: [Python-markdown-discuss] Also Deprecating mdx_* extension names?

[Waylan L. <way...@ic...>]

-----Original Message-----
From: Dave Pawson [mailto:dav...@gm...] 
Sent: Saturday, August 23, 2014 2:49 AM
To: Waylan Limberg
Cc: python-markdown-discuss
Subject: Re: [Python-markdown-discuss] Also Deprecating mdx_* extension
names?

> No objection to either proposal. Uniformity and extensibility are good.

Thanks for the feedback.

> Is there an 'ideas bucket' for future changes please?

This list is a good place to start. And github [1] issues and pull requests
provide a good way to file a request where it will be easily found again. Of
course, I prefer to keep github for actionable items, so if you just want to
discuss possibilities, then this list really is the best place.

Waylan Limberg

[1]: http:/github.com/waylan/Python-Markdown/

Re: [Python-markdown-discuss] Also Deprecating mdx_* extension names?

[Dave P. <dav...@gm...>]

No objection to either proposal. Uniformity and extensibility are good.

Is there an 'ideas bucket' for future changes please?

regards Dave P

On 22 August 2014 21:28, Waylan Limberg <way...@ic...> wrote:
> While we're talking about deprecating things related to extensions, I would
> like to deprecate support for the `mdx_*` naming convention of third party
> extensions. I updated the docs [over a year ago][1] suggesting that this
> might happen. As we support passing in instances of extension classes and
> strings using dot notation, I don't see any reason to keep this around
> except that some existing third party exceptions still use it. Although, the
> ones that do appear to not be regularly maintained which suggests they are
> not too popular.
>
> Any objections?
>
> And while I have your attention, I have also considered deprecating the
> special treatment of the included extensions. In order words, one would need
> to do `extensions=['markdown.extensions.extra']` (which has worked for some
> time, btw) rather than `extensions=['extra']. However, I feel less strongly
> about this and I realize that this would require almost all our users to
> change their code upon updating. Perhaps it would be sufficient to change
> the docs so that any mention of the special treatment  is omitted (the docs
> would suggest that all 'named extensions' would use dot notation). Any
> thoughts?
>
> Waylan Limberg
>
>
> [1]:
> https://github.com/waylan/Python-Markdown/commit/8aa2fc7b5138fd97ded7dd1e70103532a9fd6583
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Re: [Python-markdown-discuss] Also Deprecating mdx_* extension names?

[Frederik D. <fd...@gm...>]

> I would like to deprecate support for the `mdx_*` naming convention

Sounds like a good idea to me - though I'm not sure I'm qualified to
assess that. (My only extension is [Markdown Checklist].)

> I have also considered deprecating the special treatment of the
> included extensions.

I'd very much welcome that as well.

> this would require almost all our users to change their code

In that case, allow me to suggest an alternative approach: If there was
an explicit designation-package mapping for shortcuts (QName[^1]-style),
the core extensions could continue to be used just as they are now
without the need for special treatment within the code base. That is,
the default mapping might look like this:

    { # designation: package reference
        'extra': 'markdown.extensions.extra',
        'wikilinks': 'markdown.extensions.wikilinks',
        ...
    }

Thus `extensions=['extra']` would resolve - via mechanisms yet to be
determined[^2] - to `extensions=['markdown.extensions.extra']`.

This also seems to go well with the YAML/JSON config file suggested in
the adjacent thread.

(Note that it's been a while since I've dug into the source, so this
proposal might not be practical for one reason or another.)


[^1]: http://en.wikipedia.org/wiki/QName

[^2]: it might be as simple as prefixing designations with a colon to
      allow for dotless package references - or, even simpler (for users
      anyway), use the mapping only if the respective designation cannot
      be imported

[Markdown Checklist]: https://github.com/FND/markdown-checklist

[Python-markdown-discuss] Also Deprecating mdx_* extension names?

[Waylan L. <way...@ic...>]

While we're talking about deprecating things related to extensions, I would like to deprecate support for the `mdx_*` naming convention of third party extensions. I updated the docs [over a year ago][1] suggesting that this might happen. As we support passing in instances of extension classes and strings using dot notation, I don't see any reason to keep this around except that some existing third party exceptions still use it. Although, the ones that do appear to not be regularly maintained which suggests they are not too popular.

Any objections?

And while I have your attention, I have also considered deprecating the special treatment of the included extensions. In order words, one would need to do `extensions=['markdown.extensions.extra']` (which has worked for some time, btw) rather than `extensions=['extra']. However, I feel less strongly about this and I realize that this would require almost all our users to change their code upon updating. Perhaps it would be sufficient to change the docs so that any mention of the special treatment  is omitted (the docs would suggest that all 'named extensions' would use dot notation). Any thoughts?
Waylan Limberg

[1]: https://github.com/waylan/Python-Markdown/commit/8aa2fc7b5138fd97ded7dd1e70103532a9fd6583

[Python-markdown-discuss] Should we drop support for "extname(config=option)"?

[Waylan L. <way...@ic...>]

If you haven't been following along, I have recently made some changes to the config settings code for Python-Markdown extensions. In order to address [#325], the `extension_configs` keyword on the `markdown.Markdown` class now accepts a dict rather than a list of tuples (a list of tuples is still accepted for backward compatibility).[^1]

With that change made, it was rather easy to then implement an [`--extension_configs`] option on the command line which takes a file name and parses a YAML or JSON file to get the dict of extension configs which it then passes to the `extension_configs` keyword on the `markdown.Markdown` class.

As a reminder, previously, the only way to pass extension configs in from the command line was with this very limited syntax:

    $ python -m markdown -x "footnotes(PLACE_MARKER=~~~~~~~~,UNIQUE_IDS=1)" input.txt

Now that we have a better (more expressive) way to do so, the old way doesn't hold much value. After all, it allowed for no spaces or quotes and passing Boolean values or None was a little tricky. Passing Python objects was impossible (e.g.: one of the WikiLink Extension's options accepts a callable).[^2]

So, any objections to deprecating the old syntax?

A few things to note:

* We would issue a PendingDeprecationWarning with the 2.5 release and a DecrecationWarning with the 2.6 release. The feature would go away with 2.7.
* I am aware that some people have also been using this syntax from within python as well (e.g.: `markdown.markdown(text, extensions=['footnotes(PLACE_MARKER=~~~~~~~~,UNIQUE_IDS=1)'])`). Deprecating support would include this as well.
* The docs have favored passing in extension instances for a while and lists this feature as the last alternative (with a warning). If we made the change, people following the docs shouldn't be affected.
* I realize that the docs didn't always prioritize the various options properly. There could be many users who are using this anyway.
 

[^1]: Extension authors should check out the [new methods added] to the `Extension` class and how the [existing extensions] take advantage of that. No more need to reference `self.config['somekey'][0]` in your code to get or set a config setting. While the underlying data structure is the same, everything can be done through easy to use methods which hides the implementation details.

[^2]: I haven't tested it yet, but the PyYaml lib allows you to reference a python [object] through python dot notation. When the YAML file is parsed, the resulting value in the data structure will be that python object.

[#325]: https://github.com/waylan/Python-Markdown/issues/325
[`--extension_configs`]: https://github.com/waylan/Python-Markdown/commit/4100336fba3a362ac45def3aa8e79e9af76eed7e
[new methods added]: https://github.com/waylan/Python-Markdown/commit/aae373860b5c5cbb40f126bf5acb9693dc577c4a
[existing extensions]: https://github.com/waylan/Python-Markdown/commit/47372051cf9724f1355b1c07c63c4beff9a5f626
[object]: http://pyyaml.org/wiki/PyYAMLDocumentation#Objects
Waylan Limberg

Re: [Python-markdown-discuss] Cannot serialize error in custom block processor

[Waylan L. <way...@ic...>]

Trent,

Sorry for the delayed response. The error message indicates that the
serializer is coming across a non-ElementTree object in the tree (it
obviously doesn't know how to serialize it). I did a quick look through your
code and didn't see where is was coming from but perhaps that will steer you
the right direction.

Perhaps when I have some more time I'll take a closer look.

Waylan

-----Original Message-----
From: Trent "TiZ" McPheron [mailto:twi...@gm...] 
Sent: Thursday, April 24, 2014 3:58 PM
To: pyt...@li...
Subject: [Python-markdown-discuss] Cannot serialize error in custom block
processor

Hi. I'm trying to create an extension for Markdown to support the custom
HTML tags used in Dedalus, an interactive fiction system. I have the inline
stuff working perfectly fine, but I want to create a custom block type for
the <page>, <paragraph>, and <object> blocks it uses. I figured an intuitive
way to handle that would be to indent the contents.

The code I have written so far to try and accomplish this is here: 
http://pastebin.com/4pVhzeqW Right now, it dumps the following stack trace:

Traceback (most recent call last):
   File "./markded.py", line 81, in <module>
     """)
   File "/usr/lib/python2.7/site-packages/markdown/__init__.py", line 300,
in convert
     output = self.serializer(root)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line
276, in to_xhtml_string
     return _write_html(ElementTree(element).getroot(), format="xhtml")
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line
198, in _write_html
     qnames, namespaces = _namespaces(root, default_namespace)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line
264, in _namespaces
     add_qname(key)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line
244, in add_qname
     _raise_serialization_error(qname)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 78,
in _raise_serialization_error
     "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize <built-in function id> (type
builtin_function_or_method)

What am I doing wrong that is causing this error to occur? I'm not a good
Python programmer by any stretch of the imagination, and I imagine my code
is probably pretty horrible. I'm sure I am going about this completely
wrong, and I'm sure that's related to why I'm getting this error.

Thank you for your time.

----------------------------------------------------------------------------
--
Start Your Social Network Today - Download eXo Platform Build your
Enterprise Intranet with eXo Platform Software Java Based Open Source
Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your
Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Python-markdown-discuss mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

[Python-markdown-discuss] Cannot serialize error in custom block processor

[Trent \TiZ\ M. <twi...@gm...>]

Hi. I'm trying to create an extension for Markdown to support the custom 
HTML tags used in Dedalus, an interactive fiction system. I have the 
inline stuff working perfectly fine, but I want to create a custom block 
type for the <page>, <paragraph>, and <object> blocks it uses. I figured 
an intuitive way to handle that would be to indent the contents.

The code I have written so far to try and accomplish this is here: 
http://pastebin.com/4pVhzeqW Right now, it dumps the following stack trace:

Traceback (most recent call last):
   File "./markded.py", line 81, in <module>
     """)
   File "/usr/lib/python2.7/site-packages/markdown/__init__.py", line 
300, in convert
     output = self.serializer(root)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 
276, in to_xhtml_string
     return _write_html(ElementTree(element).getroot(), format="xhtml")
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 
198, in _write_html
     qnames, namespaces = _namespaces(root, default_namespace)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 
264, in _namespaces
     add_qname(key)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 
244, in add_qname
     _raise_serialization_error(qname)
   File "/usr/lib/python2.7/site-packages/markdown/serializers.py", line 
78, in _raise_serialization_error
     "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize <built-in function id> (type 
builtin_function_or_method)

What am I doing wrong that is causing this error to occur? I'm not a 
good Python programmer by any stretch of the imagination, and I imagine 
my code is probably pretty horrible. I'm sure I am going about this 
completely wrong, and I'm sure that's related to why I'm getting this error.

Thank you for your time.

Re: [Python-markdown-discuss] Can the 'meta' extension output an unchanged body minus metadata?

[Ian G. J. <ia...@ho...>]

Something like a `Body` attribute that holds the original body seems 
like it's within the scope of a MultiMarkdown metadata extension, 
because MultiMarkdown describes both how metadata and the body are 
defined.

If you think this is outside of the scope of the extension though I 
totally understand. Sprawling programs are really gross.

Ian

P.S. If anyone does know about a standalone MultiMarkdown metadata 
parser I'd love to hear about it!


On Thu, Jan 30, 2014 at 12:07:14AM +0000, Waylan Limberg wrote:
>I can't imagine how this would be useful. Isn't the point of the 
>markdown parser to parse markdown and get html? If you want to do 
>some preprocessing before passing your text into markdown, then my 
>suggestion would be to do the preprocessing before passing the text 
>into markdown. If that means reimplementing your own metadata 
>processor, then that is probably what you should do. For instance, a 
>static site generator may do this so it can allow the markup language 
>of the document to be defined in the metadata. In such a situation, 
>Python-Markdown's Metedata extension would not be the tool for the 
>job.
>
>Waylan
>
>On 1/28/2014 7:03:37 PM, "Ian G. Jeffries" <ia...@ho...> 
>wrote:
>
>>Hey folks,
>>
>>I'd like to use the 'meta' extension to get a Python string which 
>>consists of the body of the post without the metadata, but 
>>otherwise unchanged.
>>
>>I've got my own code to do this which works fine, but I was 
>>wondering if there was a built-in option to do this that I missed. 
>>If not would it be a good thing to have added?
>>
>>Cheers!
>>
>>Ian Jeffries

Re: [Python-markdown-discuss] Can the 'meta' extension output an unchanged body minus metadata?

[Waylan L. <way...@ic...>]

I can't imagine how this would be useful. Isn't the point of the 
markdown parser to parse markdown and get html? If you want to do some 
preprocessing before passing your text into markdown, then my suggestion 
would be to do the preprocessing before passing the text into markdown. 
If that means reimplementing your own metadata processor, then that is 
probably what you should do. For instance, a static site generator may 
do this so it can allow the markup language of the document to be 
defined in the metadata. In such a situation, Python-Markdown's Metedata 
extension would not be the tool for the job.

Waylan

On 1/28/2014 7:03:37 PM, "Ian G. Jeffries" <ia...@ho...> 
wrote:

>Hey folks,
>
>I'd like to use the 'meta' extension to get a Python string which 
>consists of the body of the post without the metadata, but otherwise 
>unchanged.
>
>I've got my own code to do this which works fine, but I was wondering 
>if there was a built-in option to do this that I missed. If not would 
>it be a good thing to have added?
>
>Cheers!
>
>Ian Jeffries

[Python-markdown-discuss] Can the 'meta' extension output an unchanged body minus metadata?

[Ian G. J. <ia...@ho...>]

Hey folks,

I'd like to use the 'meta' extension to get a Python string which 
consists of the body of the post without the metadata, but otherwise 
unchanged.

I've got my own code to do this which works fine, but I was wondering if 
there was a built-in option to do this that I missed. If not would it be 
a good thing to have added?

Cheers!

Ian Jeffries

Re: [Python-markdown-discuss] create markdown sublists

[Adrien S. <adr...@gm...>]

On Sat, Jan 25, 2014 at 1:44 AM, Waylan Limberg
<way...@ic...> wrote:
> Adrien,
>
> As documented[1], Python-Markdown requires four spaces of indent for nested
> lists (as the rules require).

Thank you Wayland, it is now working.
The numbering as 3.1, etc.  is not really an issue, the main problem
was to get nested lists.

Adrien

Re: [Python-markdown-discuss] create markdown sublists

[Waylan L. <way...@ic...>]

Adrien,

As documented[1], Python-Markdown requires four spaces of indent for 
nested lists (as the rules require).

However, I doubt you will get your nested list to number as 3.1, 3.2, 
...

HTML lists do not support numbering like that, so there isn't any way to 
make markdown support it. Your example should look like this:

1. item 1
2. item 2
3.
     1. item 3.1
     2. item 3.2
4. item 4

That works in almost all implementations [2]. Hope that helps.

Waylan Limberg

[1]: http://pythonhosted.org/Markdown/index.html#differences
[2]: 
http://johnmacfarlane.net/babelmark2/?normalize=1&text=1.+item+1+%0A2.+item+2+%0A3.+%0A++++1.+item+3.1+%0A++++2.+item+3.2+%0A4.+item+4+

On 1/24/2014 9:41:08 AM, "Adrien Saladin" <adr...@gm...> 
wrote:

>Hi list,
>
>Is it possible to create sub-lists with python-markdown ?
>
>I would like something like:
>
>1. item 1
>2. item 2
>3.
>   3.1 item 3.1
>   3.2 item 3.2
>4. item 4
>
>I tried some variations, including those described here:
>https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#lists
>, but it doesn't seem to work.
>
>I just wanted to know if something like this already existed.
>If not, would it be possible to write an extension to handle that ?
>
>Thanks,
>Adrien
>
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>_______________________________________________
>Python-markdown-discuss mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

[Python-markdown-discuss] create markdown sublists

[Adrien S. <adr...@gm...>]

Hi list,

Is it possible to create sub-lists with python-markdown ?

I would like something like:

1. item 1
2. item 2
3.
  3.1 item 3.1
  3.2 item 3.2
4. item 4

I tried some variations, including those described here:
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#lists
, but it doesn't seem to work.

I just wanted to know if something like this already existed.
If not, would it be possible to write an extension to handle that ?

Thanks,
Adrien

Re: [Python-markdown-discuss] Can't find code "pre" elements in Treeprocessor

[Waylan L. <wa...@gm...>]

Ah yes, that approach would work as well. Glad I could be of assistance.

----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg


On Sun, Jan 5, 2014 at 10:51 AM, edA-qa mort-ora-y <ed...@di...> wrote:
> Thank you. Since there fenced_code processor was actually small enough I
> took the easy approach: I copied the whole thing and just emitted my own
> required tags. Though I agree that a block processor would be the nicer
> approach.
>
> On 05/01/14 16:16, Waylan Limberg wrote:
>> I agree, your code should be working ... except that you are also
>> using the 'fence_code' extension. Unfortunately, the current
>> implementation of the fenced_code extension does not insert code
>> blocks into the tree, but uses the raw htmlStash to store the code
>> blocks.
>>
>> Try your source text with tradition markdown indented code blocks and
>> your code should work. If you also want to support fenced code blocks,
>> then I would suggest looking at the RawHtmlPostprocessor [1]. However,
>> you will need to manually check to make sure the raw blocks are code
>> blocks as it handles all raw html blocks - not just code.
>>
>> [1]: https://github.com/waylan/Python-Markdown/blob/master/markdown/postprocessors.py#L48
>>
>> I do have plans to refactor the fenced_code extension to be a
>> Blockprocessor (rather than a Preprocessor), but haven't had the time.
>> Doing so would solve your problem and also allow fenced code blocks to
>> be nested in lists, blockquotes, etc. As always, patches are welcome.
>> ;-)
>>
>> ----
>> \X/ /-\ `/ |_ /-\ |\|
>> Waylan Limberg
>>
>>
>> On Sun, Jan 5, 2014 at 1:18 AM, edA-qa mort-ora-y <ed...@di...> wrote:
>>> I'm trying to write an extension which translates code blocks into the
>>> Wordpress [sourcecode] form. I used codehilite as an example, but my
>>> code never finds any "pre" blocks. If I remove the 'pre' matching and
>>> print all blocks in the loop I never see a 'pre' in the list. Yet the
>>> final HTML generated does indeed have the pre/code blocks there.
>>>
>>> class WPSource(markdown.treeprocessors.Treeprocessor):
>>>         def run(self,root):
>>>                 blocks = root.getiterator('pre')
>>>                 for block in blocks:
>>>                         print(block)
>>>                         if len(children) == 1 and children[0].tag == 'code':
>>>                                 print( children[0].text )
>>>
>>> class WPExtension(markdown.Extension):
>>>         def __init__(self,configs):
>>>                 pass
>>>
>>>         def extendMarkdown(self, md, md_globals):
>>>                 sourcer = WPSource(md)
>>>                 md.treeprocessors.add("wpsource", sourcer, "_end" )
>>>                 md.registerExtension(self)
>>>
>>> md = markdown.Markdown(
>>>         extensions = [ 'meta', 'fenced_code', WPExtension({}) ]
>>> )
>>>
>>>
>>> --
>>> edA-qa mort-ora-y
>>> Leaf Creator
>>>
>>> Leaf - the language we always wanted
>>> http://leaflang.org/
>>>
>>> ------------------------------------------------------------------------------
>>> Rapidly troubleshoot problems before they affect your business. Most IT
>>> organizations don't have a clear picture of how application performance
>>> affects their revenue. With AppDynamics, you get 100% visibility into your
>>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Python-markdown-discuss mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>>
>
>
> --
> edA-qa mort-ora-y
> Leaf Creator
>
> Leaf - the language we always wanted
> http://leaflang.org/

Re: [Python-markdown-discuss] Can't find code "pre" elements in Treeprocessor

[edA-qa mort-ora-y <ed...@di...>]

Thank you. Since there fenced_code processor was actually small enough I
took the easy approach: I copied the whole thing and just emitted my own
required tags. Though I agree that a block processor would be the nicer
approach.

On 05/01/14 16:16, Waylan Limberg wrote:
> I agree, your code should be working ... except that you are also
> using the 'fence_code' extension. Unfortunately, the current
> implementation of the fenced_code extension does not insert code
> blocks into the tree, but uses the raw htmlStash to store the code
> blocks.
> 
> Try your source text with tradition markdown indented code blocks and
> your code should work. If you also want to support fenced code blocks,
> then I would suggest looking at the RawHtmlPostprocessor [1]. However,
> you will need to manually check to make sure the raw blocks are code
> blocks as it handles all raw html blocks - not just code.
> 
> [1]: https://github.com/waylan/Python-Markdown/blob/master/markdown/postprocessors.py#L48
> 
> I do have plans to refactor the fenced_code extension to be a
> Blockprocessor (rather than a Preprocessor), but haven't had the time.
> Doing so would solve your problem and also allow fenced code blocks to
> be nested in lists, blockquotes, etc. As always, patches are welcome.
> ;-)
> 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
> 
> 
> On Sun, Jan 5, 2014 at 1:18 AM, edA-qa mort-ora-y <ed...@di...> wrote:
>> I'm trying to write an extension which translates code blocks into the
>> Wordpress [sourcecode] form. I used codehilite as an example, but my
>> code never finds any "pre" blocks. If I remove the 'pre' matching and
>> print all blocks in the loop I never see a 'pre' in the list. Yet the
>> final HTML generated does indeed have the pre/code blocks there.
>>
>> class WPSource(markdown.treeprocessors.Treeprocessor):
>>         def run(self,root):
>>                 blocks = root.getiterator('pre')
>>                 for block in blocks:
>>                         print(block)
>>                         if len(children) == 1 and children[0].tag == 'code':
>>                                 print( children[0].text )
>>
>> class WPExtension(markdown.Extension):
>>         def __init__(self,configs):
>>                 pass
>>
>>         def extendMarkdown(self, md, md_globals):
>>                 sourcer = WPSource(md)
>>                 md.treeprocessors.add("wpsource", sourcer, "_end" )
>>                 md.registerExtension(self)
>>
>> md = markdown.Markdown(
>>         extensions = [ 'meta', 'fenced_code', WPExtension({}) ]
>> )
>>
>>
>> --
>> edA-qa mort-ora-y
>> Leaf Creator
>>
>> Leaf - the language we always wanted
>> http://leaflang.org/
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> 
> 


-- 
edA-qa mort-ora-y
Leaf Creator

Leaf - the language we always wanted
http://leaflang.org/

Re: [Python-markdown-discuss] Can't find code "pre" elements in Treeprocessor

[Waylan L. <wa...@gm...>]

I agree, your code should be working ... except that you are also
using the 'fence_code' extension. Unfortunately, the current
implementation of the fenced_code extension does not insert code
blocks into the tree, but uses the raw htmlStash to store the code
blocks.

Try your source text with tradition markdown indented code blocks and
your code should work. If you also want to support fenced code blocks,
then I would suggest looking at the RawHtmlPostprocessor [1]. However,
you will need to manually check to make sure the raw blocks are code
blocks as it handles all raw html blocks - not just code.

[1]: https://github.com/waylan/Python-Markdown/blob/master/markdown/postprocessors.py#L48

I do have plans to refactor the fenced_code extension to be a
Blockprocessor (rather than a Preprocessor), but haven't had the time.
Doing so would solve your problem and also allow fenced code blocks to
be nested in lists, blockquotes, etc. As always, patches are welcome.
;-)

----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg


On Sun, Jan 5, 2014 at 1:18 AM, edA-qa mort-ora-y <ed...@di...> wrote:
> I'm trying to write an extension which translates code blocks into the
> Wordpress [sourcecode] form. I used codehilite as an example, but my
> code never finds any "pre" blocks. If I remove the 'pre' matching and
> print all blocks in the loop I never see a 'pre' in the list. Yet the
> final HTML generated does indeed have the pre/code blocks there.
>
> class WPSource(markdown.treeprocessors.Treeprocessor):
>         def run(self,root):
>                 blocks = root.getiterator('pre')
>                 for block in blocks:
>                         print(block)
>                         if len(children) == 1 and children[0].tag == 'code':
>                                 print( children[0].text )
>
> class WPExtension(markdown.Extension):
>         def __init__(self,configs):
>                 pass
>
>         def extendMarkdown(self, md, md_globals):
>                 sourcer = WPSource(md)
>                 md.treeprocessors.add("wpsource", sourcer, "_end" )
>                 md.registerExtension(self)
>
> md = markdown.Markdown(
>         extensions = [ 'meta', 'fenced_code', WPExtension({}) ]
> )
>
>
> --
> edA-qa mort-ora-y
> Leaf Creator
>
> Leaf - the language we always wanted
> http://leaflang.org/
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

[Python-markdown-discuss] Can't find code "pre" elements in Treeprocessor

[edA-qa mort-ora-y <ed...@di...>]

I'm trying to write an extension which translates code blocks into the
Wordpress [sourcecode] form. I used codehilite as an example, but my
code never finds any "pre" blocks. If I remove the 'pre' matching and
print all blocks in the loop I never see a 'pre' in the list. Yet the
final HTML generated does indeed have the pre/code blocks there.

class WPSource(markdown.treeprocessors.Treeprocessor):
	def run(self,root):
		blocks = root.getiterator('pre')
		for block in blocks:
			print(block)
			if len(children) == 1 and children[0].tag == 'code':
				print( children[0].text )
		
class WPExtension(markdown.Extension):
	def __init__(self,configs):
		pass
		
	def extendMarkdown(self, md, md_globals):
		sourcer = WPSource(md)
		md.treeprocessors.add("wpsource", sourcer, "_end" )
		md.registerExtension(self)

md = markdown.Markdown(
	extensions = [ 'meta', 'fenced_code', WPExtension({}) ]
)


-- 
edA-qa mort-ora-y
Leaf Creator

Leaf - the language we always wanted
http://leaflang.org/

Re: [Python-markdown-discuss] enabling a subset of markdown

[Waylan L. <wa...@gm...>]

Ian,

That is a very ineficient way of doing it. First the entire parser has to
be built, then the whole thing gets torn back down.

Instead I would suggest subclassing the markdown.Markdown class and
overriding the 'build_parser' method [1]. That method simply calls a
function imported from each part of the parser. Each function returns an
OrderedDict. Your reimplemented method should just build the OrderedDicts
that you want. That way the default functions never get called and you only
build the parts you need. In fact, I broke that part out into a separate
method for this very purpose.

I realize that you won't be able to use an extension for this then (you'll
be using your subclass instead), but I think the difference in performance
will be worthwhile. Especially if you are using a new instance of the class
each time you run the parser.

If you would like to continue on your present course anyway, look at
those functions called by the build_parser method. You'll need to undo
everything they do, so it's a good place to start.

Hope that helps.

Waylan

[1]:
https://github.com/waylan/Python-Markdown/blob/master/markdown/__init__.py#L141

On Friday, November 1, 2013, Ian G. Jeffries wrote:

> Hey folks,
>
> I want to disable all of markdown by default and only enable certain
> features, whitelist style. Here's what I've got so far (trying to enable
> links only):
>
>
>     class MyMarkdownExtension(markdown.**Extension):
>             def extendMarkdown(self, md, md_globals):
>             for i in md.inlinePatterns.keys():
>                 if i != 'link':
>                     del md.inlinePatterns[i]
>
> The next step is to do the work to disable the other parts of
> python-markdown besides inlinePatters, but before I do that I wanted to ask
> if I'm on the right track, or if there's a better way to do this.
>
> Thanks!
>
> Ian
>


-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Python-markdown-discuss] enabling a subset of markdown

[Ian G. J. <ia...@ho...>]

Hey folks,

I want to disable all of markdown by default and only enable certain 
features, whitelist style. Here's what I've got so far (trying to enable 
links only):


     class MyMarkdownExtension(markdown.Extension):
     
         def extendMarkdown(self, md, md_globals):
             for i in md.inlinePatterns.keys():
                 if i != 'link':
                     del md.inlinePatterns[i]

The next step is to do the work to disable the other parts of 
python-markdown besides inlinePatters, but before I do that I wanted to 
ask if I'm on the right track, or if there's a better way to do this.

Thanks!

Ian