python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] Sections and other styling options

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

Igor,

The nature of the Markdown Syntax pretty much leaves raw html as your
only option to _wrap_ sections of a document.

However, if you want to add styling hooks to the various parts of the
document (say individual paragraphs), you might want to check out the
new attr_list extension [1], available in version 2.1.0.alpha [2].

[1]: https://github.com/waylan/Python-Markdown/blob/master/docs/extensions/attr_list.txt
[2]: https://github.com/waylan/Python-Markdown/downloads

2011/8/19 Igor Galić <i....@br...>:
> Hi folks,
>
> I'm working with a CMS which uses (python) Markdown as basis
> and I'm a little unhappy with the styling option that it offers.
>
> We end up with a
>
> <div id="content">
>  $mardowntext
> </div>
>
> And that is quite difficult to style sensibly.
>
> Is there any sane way -- other than wrapping a section with divs
>
> <div class="section">
> # Header # {#header1}
> Some text here
> </div>
>
> to achieve such an effect?
> I've been contemplating to add an extension for that purpose,
> which creates such section and subsection class divs, but my
> Python-fu is quite poor.
>
> Is anyone aware of such a thing already in existence? Or a
> sensible alternative? Or is putting HTML content the only
> sensible solution?
>
> Thank you for your feedback.
>
> So long,
> i
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i....@br...
> URL: http://brainsware.org/
> GPG: 571B 8B8A FC97 266D BDA3  EF6F 43AD 80A4 5779 3257
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

[Python-markdown-discuss] Sections and other styling options

[Igor G. <i....@br...>]

Hi folks,

I'm working with a CMS which uses (python) Markdown as basis
and I'm a little unhappy with the styling option that it offers.

We end up with a

<div id="content">
 $mardowntext
</div>

And that is quite difficult to style sensibly.

Is there any sane way -- other than wrapping a section with divs

<div class="section">
# Header # {#header1}
Some text here
</div>

to achieve such an effect?
I've been contemplating to add an extension for that purpose,
which creates such section and subsection class divs, but my
Python-fu is quite poor.

Is anyone aware of such a thing already in existence? Or a
sensible alternative? Or is putting HTML content the only
sensible solution?

Thank you for your feedback.

So long,
i
-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i....@br...
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3  EF6F 43AD 80A4 5779 3257

[Python-markdown-discuss] Release 2.1.0.alpha

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

I'm pleased to announce that Python-Markdown 2.1.0.alpha has just been released.

Download here: https://github.com/waylan/Python-Markdown/downloads

Read the release notes:
https://github.com/waylan/Python-Markdown/blob/master/docs/release-2.1.0-alpha.txt

Report bugs: https://github.com/waylan/Python-Markdown/issues

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

[Python-markdown-discuss] how to suppress <br> elements in paragraphs

[Brendan M. <cat...@ca...>]

I'm using python markdown, and for some reason it is substituting <br>
elements into the middle of my paragraphs whereever I have a
linebreak.

I'm just observing the convention of not having lines longer than 80
columns in my markdown files. For the purposes for formatting, I
thought the convention for markdown was to ignore newlines that don't
start a new paragraph.

Re: [Python-markdown-discuss] how to suppress <br> elements in paragraphs

[Brendan M. <cat...@ca...>]

Woops, disregard my message. I found out something else in my pipeline
was inserting that <br>'s.

On Fri, Jul 29, 2011 at 4:55 PM, Brendan Miller <cat...@ca...> wrote:
> I'm using python markdown, and for some reason it is substituting <br>
> elements into the middle of my paragraphs whereever I have a
> linebreak.
>
> I'm just observing the convention of not having lines longer than 80
> columns in my markdown files. For the purposes for formatting, I
> thought the convention for markdown was to ignore newlines that don't
> start a new paragraph.
>

Re: [Python-markdown-discuss] Future of the HeaderId extension??

[Jean-Philippe F. <co...@jp...>]

Waylan Limberg a écrit le 2011-06-29 11:28 :
> I understand your point and I even considered that when I first
> implemented it. My thinking at the time was that adding ids to headers
> it not even noticeable in the browser by the enduser reading a
> document. It doesn't change the semantics of the html at all. It just
> provides a few extra hooks (for styling or linking) which may or may
> not be used.
> 
> I don't know how many times I've wanted to link to a specific section
> of a long document and hit view-source in my browser to find the id of
> the section so I could link to `somepage.html#somesection`. It has
> always been dissatisfying to find no ids to utilize. And yet, when
> they are there, I'm completely unaware of their existence until I need
> them.

Good point, and it happens to me too.

> I find it interesting that PHP Markdown Extra's documentation [1]
> specifically states that "Setting the id attribute will work only with
> headers for now." That indicates to me that other attributes could be
> forthcoming.

Other good point.

> Therefore, I'm going to have extra use the new attr_list
> extension for defining ids (and classes and other stuff on headers and
> anything else).
> 
> [1]: http://michelf.com/projects/php-markdown/extra/#header-id
> 
> The HeaderId ext will only be used to auto-generate ids. If you want
> to define Ids, you'll need to use the attr_list extension (or extra).

It would be interesting to have a dedicated mailing list about Markdown
Extra to discuss about the evolution of its specification.

Regards,

Jean-Philippe

Re: [Python-markdown-discuss] Problem with Python 3 and Markdown 2.0.3

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

Did you run the 2to3 tool on the source first? Unfortunately, we did
not set up the tool to autorun on `setup.py install` so you have to do
it manually. Note that our next release (coming real soon and long
overdue) will fix this.

Also, note that Markdown 2.0.3 was released before Python 2.1.
Unfortunately, a workaround we included in Markdown 2.0.3 for a bug in
Python3.0's 2to3 tool breaks if you use Python 3.1+. I have not tested
whether Python3.0's 2to3 tool will generate code that works on
Python3.1+ - it might.

So, Markdown 2.0.3 only works with Python 3.0 (not greater) and only
after you manually run the 2to3 tool. I believe our documentation
indicates as much.

For more up-to-date code I suggest our github repo:
https://github.com/waylan/Python-Markdown

On Wed, Jun 29, 2011 at 12:13 PM, Vinay Sajip <vin...@ya...> wrote:
> According to PyPI, Markdown 2.0.3 is Python-3 friendly, but that's not the case
> as far as setup.py goes:
>
>
> Installing from archive: /tmp/Markdown-2.0.3.tar.gz
>  File "setup.py", line 23
>    print 'Created:', bat_path
>                   ^
> SyntaxError: invalid syntax
> failed to install
>
> Regards,
>
> Vinay Sajip
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

Re: [Python-markdown-discuss] Future of the HeaderId extension??

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

On Wed, Jun 29, 2011 at 12:00 PM, Marco Pantaleoni
<mar...@gm...> wrote:
> On Wed, Jun 29, 2011 at 5:28 PM, Waylan Limberg <wa...@gm...> wrote:
>>
>> As a side note. I've found that users tend to get confused by (and
>> therefore avoid using) extension configs. It is easy to add another
>> extension. Not so easy to change config settings for one though. In
>> other words, the typical user would rather do:
>>
>>    markdown.markdown(text, extensions=['attr_list', 'headerid'])
>>
>> rather than:
>>
>>    markdown.markdown(text, extensions=['attr_list(forceid=True)'])
>>

Keep in mind that the above syntax is only available because that's
how the comandline script takes ext configs. It just so happens that
the code that parses that is contained in the Markdown class. It is
really a coincidence that it works at all. However, as many people
have been using it, I'm not going to disable that feature.

>
> What about
>
> markdown.markdown(text, extensions=[('attr_list', {'forceid': True}), ...])
>

This is already possible through the extension_config keyword on
either the class or the wrapper function (IIRC support for this on the
function is a recent addition). Yes that means you have to list the
extension twice (extensions and configs), but that was the API before
I came to the project. We've made too many other API changes in the
past, so it is staying. I'm certainly not creating a third way.




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

[Python-markdown-discuss] Problem with Python 3 and Markdown 2.0.3

[Vinay S. <vin...@ya...>]

According to PyPI, Markdown 2.0.3 is Python-3 friendly, but that's not the case 
as far as setup.py goes:


Installing from archive: /tmp/Markdown-2.0.3.tar.gz
  File "setup.py", line 23
    print 'Created:', bat_path
                   ^
SyntaxError: invalid syntax
failed to install

Regards,

Vinay Sajip

Re: [Python-markdown-discuss] Future of the HeaderId extension??

[Marco P. <mar...@gm...>]

On Wed, Jun 29, 2011 at 5:28 PM, Waylan Limberg <wa...@gm...> wrote:

> As a side note. I've found that users tend to get confused by (and
> therefore avoid using) extension configs. It is easy to add another
> extension. Not so easy to change config settings for one though. In
> other words, the typical user would rather do:
>
>    markdown.markdown(text, extensions=['attr_list', 'headerid'])
>
> rather than:
>
>    markdown.markdown(text, extensions=['attr_list(forceid=True)'])
>
>
What about

markdown.markdown(text, extensions=[('attr_list', {'forceid': True}), ...])

or even:

markdown.markdown(text, extensions={'attr_list': {'forceid': True}, ...})

?

Even if I'd prefer the use of the OO interface, through the Markdown class,
in such cases.

-- 
Marco Pantaleoni

Re: [Python-markdown-discuss] Future of the HeaderId extension??

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

Thanks for the feedback Jean-Philippe. Some comments below:

On Sat, Jun 25, 2011 at 2:21 PM, Jean-Philippe Fleury
<co...@jp...> wrote:
> Waylan Limberg a écrit le 2011-06-23 18:39 :
>> 1) Remove HeaderID ext and reimplement those features in the attr_list
>> extension. However, as they're header specific, that doesn't feel
>> right to me.
>
> For me, it's not really inappropriate to have options related to a
> subset of attributes in the attr_list extension. I imagine options for
> ids, classes... Example (non-existent options only for this example):

You make a good point, but ...

> ~~~~~~~~~~~~~~~
> extensions=['attr_list(forceid=True, overrideClasses=False,
> optionalColon=False)']
> ~~~~~~~~~~~~~~~
>
>> 2) Remove duplicate id defining code and use the HeaderID ext only for
>> defining level and autogenerating ids on headers.
>> 3) Patch the HeaderID extension to work with setext headers and have
>> two separate extensions which accomplish the same thing - one which
>> works only with headers (and only sets ids) and the other which works
>> with any element (and sets any attribute). Seems redundant and
>> potentially confusing.
>
> I think the same code should be use to autogenerate ids on headers,
> regardless of the extension. For now, toc and headerid don't output the
> same result. toc:
>

I agree. And I think the proper place for this is in the HeaderId
Extension. If any other extension (like TOC) wants auto-generated ids,
they can use the HeaderId ext for that.

[snip]
>
> Using to the same algorithm would ensure uniformity and reduce code
> duplication. Between toc and headerid, toc algorithm is more interesting
> since its transliteration is more advanced (e.g., "intéressant" becomes
> "interessant" instead of "int+ressant").

You make a good point. I think I'll use the TOC algorithm and move it
over to the HeaderID extension.

>> 4) Do nothing and tell people to use the attr_list extension moving
>> forward for defining ids.
>
> IMHO:
>
> 1) using extensions=['extra'] should be sufficient to have full Markdown
> Extra support (without using other extensions), and a Markdown Extra
> document should be converted in HTML the same way whatever the
> implementation used (PHP, Python...). For now, we must use
> `extensions=['extra', 'headerid(forceid=False)']` to emulate correctly
> Markdown Extra, otherwise extra code (forced ids) is added that should
> not be added.

I understand your point and I even considered that when I first
implemented it. My thinking at the time was that adding ids to headers
it not even noticeable in the browser by the enduser reading a
document. It doesn't change the semantics of the html at all. It just
provides a few extra hooks (for styling or linking) which may or may
not be used.

I don't know how many times I've wanted to link to a specific section
of a long document and hit view-source in my browser to find the id of
the section so I could link to `somepage.html#somesection`. It has
always been dissatisfying to find no ids to utilize. And yet, when
they are there, I'm completely unaware of their existence until I need
them. Perhaps this was just me on a mission to make all websites (at
least the ones using python-markdown) include ids out of the box.

>
> 2) when using extensions=['extra'], extra elements that are not part of
> the Markdown Extra description should not be accessible, otherwise we
> open the door to a set of Markdown Extra documents not converted the
> same way according to the implementation used.

I find it interesting that PHP Markdown Extra's documentation [1]
specifically states that "Setting the id attribute will work only with
headers for now." That indicates to me that other attributes could be
forthcoming. Therefore, I'm going to have extra use the new attr_list
extension for defining ids (and classes and other stuff on headers and
anything else).

[1]: http://michelf.com/projects/php-markdown/extra/#header-id

The HeaderId ext will only be used to auto-generate ids. If you want
to define Ids, you'll need to use the attr_list extension (or extra).

As a side note. I've found that users tend to get confused by (and
therefore avoid using) extension configs. It is easy to add another
extension. Not so easy to change config settings for one though. In
other words, the typical user would rather do:

    markdown.markdown(text, extensions=['attr_list', 'headerid'])

rather than:

    markdown.markdown(text, extensions=['attr_list(forceid=True)'])

My proposed changes give them that. Besides, we are only 'forceing
ids' on headers. Not all elements that attributes can be defined on in
the attr_list ext.

Additionally, the first example is also doable with Django's markdown
template tag. IIRC the second is not. Of course that should not be the
controlling factor here, but it is an interesting datapoint.


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

Re: [Python-markdown-discuss] Future of the HeaderId extension??

[Jean-Philippe F. <co...@jp...>]

Waylan Limberg a écrit le 2011-06-23 18:39 :
> 1) Remove HeaderID ext and reimplement those features in the attr_list
> extension. However, as they're header specific, that doesn't feel
> right to me.

For me, it's not really inappropriate to have options related to a
subset of attributes in the attr_list extension. I imagine options for
ids, classes... Example (non-existent options only for this example):

~~~~~~~~~~~~~~~
extensions=['attr_list(forceid=True, overrideClasses=False,
optionalColon=False)']
~~~~~~~~~~~~~~~

> 2) Remove duplicate id defining code and use the HeaderID ext only for
> defining level and autogenerating ids on headers.
> 3) Patch the HeaderID extension to work with setext headers and have
> two separate extensions which accomplish the same thing - one which
> works only with headers (and only sets ids) and the other which works
> with any element (and sets any attribute). Seems redundant and
> potentially confusing.

I think the same code should be use to autogenerate ids on headers,
regardless of the extension. For now, toc and headerid don't output the
same result. toc:

~~~~~~~~~~~~~~~
text = """
# L'intéressant titre
"""
print markdown.markdown(text, extensions=['toc'])
~~~~~~~~~~~~~~~

will output:

~~~~~~~~~~~~~~~
<h1 id="linteressant-titre">L'intéressant titre</h1>
~~~~~~~~~~~~~~~

headerid:

~~~~~~~~~~~~~~~
text = """
# L'intéressant titre
"""
print markdown.markdown(text, extensions=['headerid'])
~~~~~~~~~~~~~~~

will output:

~~~~~~~~~~~~~~~
<h1 id="lint+ressant_titre">L'intéressant titre</h1>
~~~~~~~~~~~~~~~

Using to the same algorithm would ensure uniformity and reduce code
duplication. Between toc and headerid, toc algorithm is more interesting
since its transliteration is more advanced (e.g., "intéressant" becomes
"interessant" instead of "int+ressant").

> 4) Do nothing and tell people to use the attr_list extension moving
> forward for defining ids.

IMHO:

1) using extensions=['extra'] should be sufficient to have full Markdown
Extra support (without using other extensions), and a Markdown Extra
document should be converted in HTML the same way whatever the
implementation used (PHP, Python...). For now, we must use
`extensions=['extra', 'headerid(forceid=False)']` to emulate correctly
Markdown Extra, otherwise extra code (forced ids) is added that should
not be added.

2) when using extensions=['extra'], extra elements that are not part of
the Markdown Extra description should not be accessible, otherwise we
open the door to a set of Markdown Extra documents not converted the
same way according to the implementation used.

> I'm leaning toward #2 myself. But is also occurs to me that the TOC
> extension also autogenerates ids when not defined (in a slightly
> different manner). Perhaps we should provide some general code
> specifically for autogenerating ids on headers.

I think so, but I don't know if it should be as an extension or not.

Regards,

Jean-Philippe

[Python-markdown-discuss] Future of the HeaderId extension??

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

I have a question about the HeaderID extension and what should happen to it.

To summarize, a bug report [1] was filed recently pointing out that
ids can not be set on setext style headers. At first I was just going
to fix it, but instead I added a new extension [2] implementing
attribute lists (inspired by Maruku [3]). The new extension adds the
same behavior and more (allowing classes and other attributes as
well). I even implemented the syntax with the colon optional so
existing documents would not need to be edited.

However, if I remove the HeaderID extension we loose 2 features which
it provides: the ability to define a starting header level and
automatically generated ids on headers. (see the docs [4])

I see the following options and would like some feedback about what
others would prefer.

1) Remove HeaderID ext and reimplement those features in the attr_list
extension. However, as they're header specific, that doesn't feel
right to me.
2) Remove duplicate id defining code and use the HeaderID ext only for
defining level and autogenerating ids on headers.
3) Patch the HeaderID extension to work with setext headers and have
two separate extensions which accomplish the same thing - one which
works only with headers (and only sets ids) and the other which works
with any element (and sets any attribute). Seems redundant and
potentially confusing.
4) Do nothing and tell people to use the attr_list extension moving
forward for defining ids.

I'm leaning toward #2 myself. But is also occurs to me that the TOC
extension also autogenerates ids when not defined (in a slightly
different manner). Perhaps we should provide some general code
specifically for autogenerating ids on headers. I suppose the HeaderID
extension could serve that purpose (especially if we went with option
2), or should  that be something configurable on the Markdown class.
Leaving it as an extension would make the autogenerating algorism more
easily overridable.

The other consideration is that the Extra extension currently includes
the HeaderID extension. If we went with option #2, we would need to
use the attr_list extension. But PHP Markdown Extra doesn't offer the
header level and auto ids options, so that means the HeaderId
extension would be removed from our version of Extra as well. I wonder
if that could cause frustration from people using Extra and relying on
those features. If this is a real issue, I have no idea if option #1
or #4 would be the best way forward.

Any thoughts?

[1]: https://github.com/waylan/Python-Markdown/issues/16
[2]: https://github.com/waylan/Python-Markdown/blob/master/docs/extensions/attr_list.txt
[3]: http://maruku.rubyforge.org/proposal.html#attribute_lists
[4]: https://github.com/waylan/Python-Markdown/blob/06004bd900b7425641932d27f0bb5a77fadfcff5/docs/extensions/HeaderId.txt

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

Re: [Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

[Brian N. <bg...@gm...>]

Waylan,

Yes, absolutely you have my permission! I've been using it for months
and so far it seems to work as expected with a variety of inputs.

Thanks for including it and thanks for designing Python-Markdown with
such a useful extension facility!

Best regards,
BN

On Tue, Jun 21, 2011 at 9:31 AM, Waylan Limberg <wa...@gm...> wrote:
> Brian,
>
> We've received at least one request [1] for your Nl2Br extension [2]
> to be distributed with Python-Markdown. Unlike some requests, I think
> this one could be useful to a larger number of people. If you're not
> opposed, I'll include a copy in our extensions dir with the credit to
> you.
>
> Thanks,
> Waylan
>
> [1]: https://github.com/waylan/Python-Markdown/issues/13
> [2]: http://deathofagremmie.com/2011/05/09/a-newline-to-break-python-markdown-extension/
>

Re: [Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

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

Brian,

We've received at least one request [1] for your Nl2Br extension [2]
to be distributed with Python-Markdown. Unlike some requests, I think
this one could be useful to a larger number of people. If you're not
opposed, I'll include a copy in our extensions dir with the credit to
you.

Thanks,
Waylan

[1]: https://github.com/waylan/Python-Markdown/issues/13
[2]: http://deathofagremmie.com/2011/05/09/a-newline-to-break-python-markdown-extension/

On Thu, Mar 3, 2011 at 10:43 AM, Brian Neal <bg...@gm...> wrote:
> On Thu, Mar 3, 2011 at 9:23 AM, Waylan Limberg <wa...@gm...> wrote:
>> On Wed, Mar 2, 2011 at 9:52 PM, Brian Neal <bg...@gm...> wrote:
>>> Hi -
>>>
>>> After some head scratching I came up with something super simple (as
>>> Waylan said it might be) and it actually seems to work, so far. Before
>>> I publish it somewhere for good I'm wondering if you guys would give
>>> it a quick peer review. Does this look reasonable?
>>>
>>> http://dpaste.com/hold/467237/
>>>
>>
>> That looks good to me. However, what happens when Markdown line break
>> syntax (two spaces followed by a newline) is encountered? I'm
>> wondering if this will add a second linebreak. If so, you should
>> probably remove that pattern.
>>
>
> I've tried this too and it does the right thing. No extra break is inserted.
>
> Thanks,
> BN
>



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

Re: [Python-markdown-discuss] HTML Comments getting munged somehow

[Steven L S. <ssm...@zi...>]

Thanks for the answer, Waylan.

I guess I misunderstood the order of how things get processed.

I ended up replacing my syntax with ~naz:showhide and ~/naz:showhide, and moving the order of my extension like you suggested, and it worked.



====================================
Steven L Smith, Web Developer
Department of Information Technology Services
Nazareth College of Rochester
585-389-2085 | ssm...@na... | KC2YTC
http://www.naz.edu/pub/~ssmith46
====================================

----- Original Message -----
From: "Waylan Limberg" <wa...@gm...>
To: "Steven L Smith" <ssm...@na...>
Sent: Thursday, June 16, 2011 11:19:16 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Python-markdown-discuss] HTML Comments getting munged somehow

On Thu, Jun 16, 2011 at 10:34 AM, Steven L Smith
<ssm...@zi...> wrote:
[snip]
> My preprocessor basically says 'if the line is <!-- naz:showhide -->, replace it with <div class="showhide">'.
>
> In 2.0.3, I could do this with basic string operations, but in the trunk, the comments are stored in the "lines" list as some sort of weird string, and they're no longer matching. For example, "<!-- naz:showhide -->" is "\x02wzxhzdk:0\x03" by the time it gets to my extension.
>

That is the placeholder string for the raw html. It will be swapped
out for the raw html later. Make sure your extension runs before the
raw html preprocessor and you should be good (not sure why this would
have changed since 2.0.3 either). Although, If I am understanding what
your extension does, that means the markdown text will be wrapped in a
div and won't get processed (per expected markdown behavior). Perhaps
you should run a postprocessor after the "raw_html" postprocessor has
swapped the placeholders back out for the raw html.

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

[Python-markdown-discuss] HTML Comments getting munged somehow

[Steven L S. <ssm...@zi...>]

I'm writing an extension that will let our users use markdown to apply particular styles as wrapper divs, without making them learn how to properly open and close div tags.

So, I thought that using HTML comments would be a good idea, since, if you don't have our CSS running, the extension would simply output valid code without littering it with useless, formatting-only stuff.

Essentially, I have stuff like this:
<!-- naz:showhide -->
## Headline ##
### Subhead ###
Showhide body copy lorem ipsum
### Subhead ###
More body copy dolor sit amet
<!-- /naz:showhide -->

My preprocessor basically says 'if the line is <!-- naz:showhide -->, replace it with <div class="showhide">'.

In 2.0.3, I could do this with basic string operations, but in the trunk, the comments are stored in the "lines" list as some sort of weird string, and they're no longer matching. For example, "<!-- naz:showhide -->" is "\x02wzxhzdk:0\x03" by the time it gets to my extension.

I tried to dig through the commit logs to see where this changed, but came up empty.

Any suggestions of what to try next?

Thanks!

====================================
Steven L Smith, Web Developer
Department of Information Technology Services
Nazareth College of Rochester
585-389-2085 | ssm...@na... | KC2YTC
http://www.naz.edu/pub/~ssmith46
====================================

Re: [Python-markdown-discuss] URLs failing to match Wayback Archive URLs

[Alan H. <co...@al...>]

My apologies. The error seems to be arising because the sanitizer I’m using is stripping quotes, which would be perfectly valid, except for that then jQuery mis-parses the output. More info here: http://bugs.jquery.com/ticket/9530

Alan

On Monday, June 6, 2011 at 10:33 AM, Waylan Limberg wrote:

> On Mon, Jun 6, 2011 at 1:13 PM, Alan Hogan <co...@al... (mailto:co...@al...)> wrote:
> > I noticed today that Python-Markdown doesn’t transform angle-bracket syntax
> > links when they link to pages on the Wayback machine (probably because they
> > have a URL within a URL).
> 
> This appears to be working fine for me. Which version are you using?
> Do you perhaps have safe_mode enabled?
> 
> >>> markdown.markdown('<http://web.archive.org/web/20100304221756/h
>  ttp://www.yahoo.com (http://www.yahoo.com)/>')
>  u'<p><a href="http://web.archive.org/web/20100304221756/http://www.yah
>  oo.com/">http://web.archive.org/web/20100304221756/http://www.yahoo.c
>  om/</a></p>'
> 
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg

Re: [Python-markdown-discuss] URLs failing to match Wayback Archive URLs

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

On Mon, Jun 6, 2011 at 1:13 PM, Alan Hogan <co...@al...> wrote:
> I noticed today that Python-Markdown doesn’t transform angle-bracket syntax
> links when they link to pages on the Wayback machine (probably because they
> have a URL within a URL).

This appears to be working fine for me. Which version are you using?
Do you perhaps have safe_mode enabled?

    >>> markdown.markdown('<http://web.archive.org/web/20100304221756/h
    ttp://www.yahoo.com/>')
    u'<p><a href="http://web.archive.org/web/20100304221756/http://www.yah
    oo.com/">http://web.archive.org/web/20100304221756/http://www.yahoo.c
    om/</a></p>'

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

[Python-markdown-discuss] URLs failing to match Wayback Archive URLs

[Alan H. <co...@al...>]

I noticed today that Python-Markdown doesn’t transform angle-bracket syntax links when they link to pages on the Wayback machine (probably because they have a URL within a URL). 

I consider this a bug, as there is no problem with such a hyperlink in practice.

http://web.archive.org/web/20100304221756/http://www.yahoo.com/

In fact, my email client just highlighted the above line as a link; clicking it works perfectly.

Alan

Re: [Python-markdown-discuss] Bug with different list types

[Alan H. <ala...@gm...>]

Insidious!

Thanks for the response. I’ve fired off what I hope to be a reasonable plea stating my case to the Markdown mailing list.

+1s will be appreciated!

Alan

On Tuesday, May 31, 2011 at 7:27 AM, Waylan Limberg wrote:

> On Tue, May 31, 2011 at 5:13 AM, Alan Hogan <ala...@gm... (mailto:ala...@gm...)> wrote:
> > If you have a bulleted list followed by a numbered list, or vice-versa, this
> > library converts all the following list elements to the first element's
> > type. Even when there is a blank line between lists.
> 
> Correct, a blank line does not start a new list but indicates that the
> contents of the list items should be wrapped in <p> tags. Therefore
> blanks lines will never start a new list.
> 
> Regarding the change of list type, as you note, Gruber's
> implementation ignores that as well. As he created Markdown he gets to
> decide how that is implemented. Until his implementation is updated,
> Python-Markdown will continue to support the current behavior. Btw,
> this issue has been debated to no end on the markdown mailing list.
> But the result is always the same.
> 
> Of course, using our extension API [1], you could build your own list
> parser which would replace the default and have whatever behavior you
> want. We just won't include that in our default implementation.
> 
> [1]: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg

Re: [Python-markdown-discuss] Bug with different list types

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

On Tue, May 31, 2011 at 5:13 AM, Alan Hogan <ala...@gm...> wrote:
> If you have a bulleted list followed by a numbered list, or vice-versa, this
> library converts all the following list elements to the first element's
> type. Even when there is a blank line between lists.

Correct, a blank line does not start a new list but indicates that the
contents of the list items should be wrapped in <p> tags. Therefore
blanks lines will never start a new list.

Regarding the change of list type, as you note, Gruber's
implementation ignores that as well. As he created Markdown he gets to
decide how that is implemented. Until his implementation is updated,
Python-Markdown will continue to support the current behavior. Btw,
this issue has been debated to no end on the markdown mailing list.
But the result is always the same.

Of course, using our extension API [1], you could build your own list
parser which would replace the default and have whatever behavior you
want. We just won't include that in our default implementation.

[1]: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions
-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Python-markdown-discuss] Bug with different list types

[Alan H. <ala...@gm...>]

If you have a bulleted list followed by a numbered list, or vice-versa, this library converts all the following list elements to the first element's type. Even when there is a blank line between lists.

Screenshots of input and output:

http://cl.ly/1C271N0R363k1Z2b1S27
http://cl.ly/2X3F460e2A2H3t243Q0i

Note Gruber’s dingus has the same output, which I still consider erroneous:

http://cl.ly/2p3Q2W0d3D0L1Z0a3f0s

Alan

Re: [Python-markdown-discuss] validating syntax of user input

[gordon p. <wgo...@gm...>]

Waylan,

Thanks for the reply.  It is good to know the markdown parser can handle any
input without choking.  I will just use a simple lambda function that
returns no errors as a validator to add markdown to my system.

-- Gordon

On Wed, May 4, 2011 at 2:01 PM, Waylan Limberg <wa...@gm...> wrote:

> Gordon,
>
> AFAIK there is no Markdown validator. Markdown parsers generally are
> expected to be able to take any text string and parse it. Of course,
> if the input is not valid markdown syntax, the returned result will
> not be as expected - but the end user should be able to see the
> undesired results and make edits. This is a feature, not a bug.
> Perhaps you need to implement a preview step for your users for this
> purpose.
>
> BTW, our markdown parser should never choke on any input text. If
> you're aware of input which raises an error, that is a bug (please
> file a report [1]). The parser should just be passing unrecognized
> syntax through unmodified. Of course, the parser may misinterpret
> non-markdown syntax as markdown syntax which results in odd output.
> That is not a bug - just bad input which should be edited in the
> preview stage. I suggest testing some questionable input on numerous
> markdown implementations  using Babelmark [2] to see what I mean.
>
> If you want to filter out specific types of input that normally would
> get passed through (and our "safe mode" won't cover it), you should be
> looking for a separate filtering library - which could either filter
> before or after the markdown parser. See bleach [3] as an example.
>
> [1]: http://github.com/waylan/Python-Markdown/issues
> [2]: http://babelmark.bobtfish.net
> [3]: http://github.com/jsocol/bleach
>
> On Tue, May 3, 2011 at 5:48 PM, gordon pendleton <wgo...@gm...>
> wrote:
> > Hi,
> >
> > I am adding the Markdown markup language as an option for user input into
> my
> > web app.  I need to be able to validate the syntax of user submitted
> content
> > to ensure the markup will render properly before accepting the
> submission.
> > How can I verify that the input contains valid Markdown syntax?  I did
> not
> > see any error reporting mechanisms I could hook into in the code.  How
> > should I go about this?
> >
> > Thanks,
> > Gordon
> >
> >
> ------------------------------------------------------------------------------
> > WhatsUp Gold - Download Free Network Management Software
> > The most intuitive, comprehensive, and cost-effective network
> > management toolset available today.  Delivers lowest initial
> > acquisition cost and overall TCO of any competing solution.
> > http://p.sf.net/sfu/whatsupgold-sd
> > _______________________________________________
> > Python-markdown-discuss mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> >
> >
>
>
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>

Re: [Python-markdown-discuss] validating syntax of user input

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

Gordon,

AFAIK there is no Markdown validator. Markdown parsers generally are
expected to be able to take any text string and parse it. Of course,
if the input is not valid markdown syntax, the returned result will
not be as expected - but the end user should be able to see the
undesired results and make edits. This is a feature, not a bug.
Perhaps you need to implement a preview step for your users for this
purpose.

BTW, our markdown parser should never choke on any input text. If
you're aware of input which raises an error, that is a bug (please
file a report [1]). The parser should just be passing unrecognized
syntax through unmodified. Of course, the parser may misinterpret
non-markdown syntax as markdown syntax which results in odd output.
That is not a bug - just bad input which should be edited in the
preview stage. I suggest testing some questionable input on numerous
markdown implementations  using Babelmark [2] to see what I mean.

If you want to filter out specific types of input that normally would
get passed through (and our "safe mode" won't cover it), you should be
looking for a separate filtering library - which could either filter
before or after the markdown parser. See bleach [3] as an example.

[1]: http://github.com/waylan/Python-Markdown/issues
[2]: http://babelmark.bobtfish.net
[3]: http://github.com/jsocol/bleach

On Tue, May 3, 2011 at 5:48 PM, gordon pendleton <wgo...@gm...> wrote:
> Hi,
>
> I am adding the Markdown markup language as an option for user input into my
> web app.  I need to be able to validate the syntax of user submitted content
> to ensure the markup will render properly before accepting the submission.
> How can I verify that the input contains valid Markdown syntax?  I did not
> see any error reporting mechanisms I could hook into in the code.  How
> should I go about this?
>
> Thanks,
> Gordon
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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