python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] Ticket 18: DEBUG log setting

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

Mike thanks for the bug report on Ticket 18 [1]. I'm copying the list
with my response.

> markdown.py has a hardcoded logging setting of DEBUG,
> which allows all DEBUG messages to go out to all
> configured handlers. There's then a comment which says
> something to the effect of "this is restricted by handlers
> later". I'd like to propose that this is the incorrect usage
> of logging

Actually, based on my testing the current behavior is correct. Suppose
we set the logger to CRITICAL. Then, someone adds a handler (perhaps
that writes to a log file) set to DEBUG. Because the logger only
allows CRITICAL messages through, the handler would never receive
anything less than CRITICAL even though its set to DEBUG. That's
unacceptable - and why the logger is wide open and the handlers later
restrict the level.

The intention is that users would set (and/or remove) handlers and set
the level for each handler as they need. In fact, we realize that the
StreamHandler will break in some web server environments (it's
indented for command line use) and may need to be removed/replaced
with a handler appropriate for your system. That's why we recently
adopted use of  Python's logger rather than our own old inflexible
home-grown solution. It's much easier to override handlers than
monkeypatch the old system.

> The workaround for now is that you have to hardcode a call
> to "logging.getLogger("MARKDOWN").setLevel(logging.WARN)"
> to silence the MARKDOWN logger in your application code

Actually I envisioned something very similar, except altering the
*handler* attached to the logger, not the logger itself. Perhaps it's
not the most convenient (in that it doesn't integrate with your
environment's settings file), but a solution that will work in a
variety of different situations is certainly welcome. I'm not
personally familiar with Pylons and/or Paste, but would certainly like
to see easy use of markdown in such a context. At the same time,
markdown needs to continue to work as it does now from the command
line as well as in other environments.

If anyone has any suggestions and/or solutions I'm all ears.

[1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000018

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] second Markdown() instance clobbers the first?

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

On Sat, Oct 4, 2008 at 3:12 PM, Yuri Takhteyev <qar...@gm...> wrote:
>
> I think we have two options: we can either make all the patterns
> stateless, and give them an instance of Markdown() if they want to
> look up config parameters.  Or we could give each instance of Markdown
> it's own set of patterns.  I am leaning on the second solution, but
> note the downside: the we are relying on those variables in the
> extensions, so this would break many of the extensions.  If we'll be
> doing this, we might as well make the effort now to add a treap for
> ordering the preprocessor, as Ben Wilson suggested last year.
>
[snip]
>
> What do you guys think?
>

I agree. I'm leaning toward the second option as well. Btw, Ben must
have failed to copy the list on the last few emails he sent you
because last I knew we was still working on it. Yet, a few times since
then, you've made some comments that seem to indicate you saw some
code of his.

In any event, if we are going to do anything link this, it should
definitely be before we release 2.0. The move to ET already broke
existing extensions and seeing we havn't released since then, we might
as well keep going with the changes. I suspect most people are still
using 1.7 with any private extensions they've written so they'll have
to update witht he next release anyway.

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] second Markdown() instance clobbers the first?

[Yuri T. <qar...@gm...>]

Your expectations are correct, the behavior is wrong, so it's a bug.

The reason for this is that it looks like different instances of
Markdown share the same instances of patterns.  For instance, we have:

REFERENCE_PREPROCESSOR = ReferencePreprocessor()

So, REFERENCE_PREPROCESSOR is a module-level variable and the instance
is shared.  This gives later instances an opportunity to change it
during initialization.

I think we have two options: we can either make all the patterns
stateless, and give them an instance of Markdown() if they want to
look up config parameters.  Or we could give each instance of Markdown
it's own set of patterns.  I am leaning on the second solution, but
note the downside: the we are relying on those variables in the
extensions, so this would break many of the extensions.  If we'll be
doing this, we might as well make the effort now to add a treap for
ordering the preprocessor, as Ben Wilson suggested last year.

Then, we would have something like:

    self.preprocessors = Treap('header', HeaderPreprocessor())
    self.preprocessors.insert_after('header', 'line', LinePreprocessor())
    self.preprocessors.insert_after('line', 'reference',
ReferencePreprocessor())

In the footnote extension we can then have:

    md.preprocessors.insert_before('reference', 'footnote',
FootnotePreprocessor())

What do you guys think?

- yuri

On Thu, Sep 25, 2008 at 11:39 PM, Eric Abrahamsen <er...@ab...> wrote:
> I'm using Markdown with Django, not as a template filter but by
> running database text through markdown as it is saved, so that the
> markdown text is saved into one field, and HTML converted text is
> saved into another field. I want different behavior for different
> models, so I instantiate two Markdown objects, one for filtering blog
> entry text (safe_mode is off) and one for filtering comment text
> (safe_mode is set to 'remove').
>
> Both are instantiated at the top of a single models.py module, like
> this:
>
> safe_md = Markdown()
> remove_md = Markdown(safe_mode='remove')
>
> What I've found is that the second instance seems to override the
> first. Blog text run through safe_md.convert() has its HTML removed,
> as though its safe_mode were set to 'remove'. I "fixed" the problem by
> commenting out the second instance, and later I moved it inside a
> function where it's hidden.
>
> This isn't at all how I expected this to work, and I wonder if it's a
> bug with Markdown or with my expectations. I thought it might have had
> to do with Django, perhaps threading or something, but it behaves the
> same way in the Python interpreter. Can someone explain what's going
> on here?
>
> TIA,
>
> Eric
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://sputnik.freewisdom.org/

[Python-markdown-discuss] wrapping character ranges in tags

[Eric A. <gi...@gm...>]

Hi there,

I've made a custom inline pattern to wrap Chinese characters in <span  
class="char"></span> tags, using a regex (Chinese characters generally  
fall between \u4e00 and \u9fff).

The below works, but wraps each individual character in its own span  
tags, rather than wrapping consecutive runs of characters in a single  
set of tags:

class SpanPattern(markdown.Pattern):
     def handleMatch(self, m, doc):
         el = doc.createElement('span')
         el.appendChild(doc.createTextNode(m.group(2)))
         el.setAttribute('class','char')
         return el

md.inlinePatterns.insert(-1,SpanPattern(ur'([\u4e00-\u9fff]+)'))

The result is the same whether the + is included in the regex or not;  
is there some other trick I can use to make sure that five characters  
in row, for instance, will get wrapped together in one pair of spans?

TIA,

Eric

[Python-markdown-discuss] second Markdown() instance clobbers the first?

[Eric A. <er...@ab...>]

I'm using Markdown with Django, not as a template filter but by  
running database text through markdown as it is saved, so that the  
markdown text is saved into one field, and HTML converted text is  
saved into another field. I want different behavior for different  
models, so I instantiate two Markdown objects, one for filtering blog  
entry text (safe_mode is off) and one for filtering comment text  
(safe_mode is set to 'remove').

Both are instantiated at the top of a single models.py module, like  
this:

safe_md = Markdown()
remove_md = Markdown(safe_mode='remove')

What I've found is that the second instance seems to override the  
first. Blog text run through safe_md.convert() has its HTML removed,  
as though its safe_mode were set to 'remove'. I "fixed" the problem by  
commenting out the second instance, and later I moved it inside a  
function where it's hidden.

This isn't at all how I expected this to work, and I wonder if it's a  
bug with Markdown or with my expectations. I thought it might have had  
to do with Django, perhaps threading or something, but it behaves the  
same way in the Python interpreter. Can someone explain what's going  
on here?

TIA,

Eric

[Python-markdown-discuss] nested list in markdown

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

On Thu, Sep 25, 2008 at 9:10 AM, Benoit Chesneau <be...@co...> wrote:
>
> On 25 sept. 08, at 15:07, Waylan Limberg wrote:
>
>> Hi Benoit,
>>
>> I justed edited that page you linked to and it works fine. The problem
>> is that python-markdown *requires* four spaces of indent and you only
>> had two. I realize some other implementations of markdown are not so
>> strict about that, but the way python-markdown works it's not easy to
>> make it more lax.
>>
>> I'm not sure why your preview was working.
>>
>
> Mmmm the markdown syntax don't require 4 4 spaces, isn't it ?
>

This has been a point of contention on the general markdown list from
time to time. It seems that most prefer the more lax interpretation -
but not everyone. The code in that part of python-markdown is some of
the oldest code and we really need to refactor it. If/when we do,
hopefully it'll be able to understand more lax indentation.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] nested list in markdown

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

Hi Benoit,

I justed edited that page you linked to and it works fine. The problem
is that python-markdown *requires* four spaces of indent and you only
had two. I realize some other implementations of markdown are not so
strict about that, but the way python-markdown works it's not easy to
make it more lax.

I'm not sure why your preview was working.

On Thu, Sep 25, 2008 at 8:26 AM, Benoit Chesneau <be...@co...> wrote:
> Hi all,
>
> For http://couch.it I decided to use python-markdown due to its
> possibilites of extension. I use lates trunk, but I have some problem
> with nested list like reported here :
>
> http://wiki.couch.it/Bugs_and_Issues
>
>
> Any idee what could be the problem ? Anyone already had this problem ?
>
> - benoît
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
Waylan Limberg
wa...@gm...

[Python-markdown-discuss] nested list in markdown

[Benoit C. <be...@co...>]

Hi all,

For http://couch.it I decided to use python-markdown due to its  
possibilites of extension. I use lates trunk, but I have some problem  
with nested list like reported here :

http://wiki.couch.it/Bugs_and_Issues


Any idee what could be the problem ? Anyone already had this problem ?

- benoît

Re: [Python-markdown-discuss] The WikiLinks Conundrum

[Neale P. <ne...@wo...>]

"Waylan Limberg" <wa...@gm...> writes:

> Oh, I should also point out that I have already resolved the problems
> with the placeholders. That's not at all the issue I'm talking about
> here. Of course, perhaps if your reimplementing some of the way inline
> patterns work, that might make a difference.

Actually I don't think my changes would help with this particular
problem.  I was just using the thread as an "in" to discuss what I was
working on.  ;)

Neale

Re: [Python-markdown-discuss] The WikiLinks Conundrum

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

Oh, I should also point out that I have already resolved the problems
with the placeholders. That's not at all the issue I'm talking about
here. Of course, perhaps if your reimplementing some of the way inline
patterns work, that might make a difference.

On Fri, Sep 5, 2008 at 11:56 PM, Neale Pickett <ne...@wo...> wrote:
> I'm currently working on a gigantic patch that completely eliminates
> placeholders and stashes.
>
> I don't know if this is going to even work yet, so don't hold your
> breath.  But if it does work it should eliminate all these kludges to
> prevent patterns from matching placeholders and allow a WikiLink
> extension to work with no problems.
>
> Neale
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] The WikiLinks Conundrum

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

Neale, I'd be interested in seeing your progress on this. Feel free to
create a clone on Gitorious (anyone can) and push your changes. That
way, other's can track what your doing and maybe even offer input. I
look forward to hearing more.

On Fri, Sep 5, 2008 at 11:56 PM, Neale Pickett <ne...@wo...> wrote:
> I'm currently working on a gigantic patch that completely eliminates
> placeholders and stashes.
>
> I don't know if this is going to even work yet, so don't hold your
> breath.  But if it does work it should eliminate all these kludges to
> prevent patterns from matching placeholders and allow a WikiLink
> extension to work with no problems.
>
> Neale
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] The WikiLinks Conundrum

[Neale P. <ne...@wo...>]

I'm currently working on a gigantic patch that completely eliminates
placeholders and stashes.

I don't know if this is going to even work yet, so don't hold your
breath.  But if it does work it should eliminate all these kludges to
prevent patterns from matching placeholders and allow a WikiLink
extension to work with no problems.

Neale

Re: [Python-markdown-discuss] The WikiLinks Conundrum

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

On Fri, Sep 5, 2008 at 4:52 PM, Blake Winton <bw...@la...> wrote:
> Waylan Limberg wrote:
>> The problem is that CamelCase words that correctly appear in other
>> parts of the markup are mistakenly being identified as wikilinks.
>>
>> In the past this was not a problem because any markup in the labels
>> was ignored. Now that that bug is squished, I need a way to tell
>> markdown to not run the WikiLink pattern against the label. There are
>> currently two mechanisms to do that. One it to set each label as an
>> AtomicString. However, then we would again be back were we were with
>> nested markup being ignored in labels.
>
> Ooh, ooh!  SemiAtomicString?  ;)
>
>> The other solution is to reorder the InlinePatterns.
>
> I think that having patterns be order dependant isn't a great idea, in
> general.
>
> Could the WikiLink pattern be made more context-sensitive somehow,
> so that it wouldn't match if there it was inside a "Label"?
>
>> Interestingly, it
>> occurred to me that if InlinePattern was passed the parent element, we
>> could test ``parent_elem.tag != 'a'``, but even then, if that
>> CamelCase word is nested in strong or em tags, that test would fail.
>> Besides, I can't think of any other use for doing that.
>
> Well, if you could walk up your parents, you could check all of them for
> an 'a' (and check whether you were an attribute).  It seems like it
> might be worth defining a couple of custom walkers, to handle cases
> where we want to expand stuff, but only if it occurs in
> non-link/non-attribute places.
>
This was my initial thought as well. I guess I left out the fact that
ElementTree doesn't track parents of an Element - only children. Grrr.
Although, the project website does offer some sample code [1] that can
be used to walk the entire tree from root and generate a list of all
parents of an element. Seemed like an awful lot of extra work just to
check a parent - I'm sure we'd take a performance (and memory?) hit
with it.

[1]: http://effbot.org/zone/element.htm#accessing-parents

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] The WikiLinks Conundrum

[Blake W. <bw...@la...>]

Waylan Limberg wrote:
> The problem is that CamelCase words that correctly appear in other
> parts of the markup are mistakenly being identified as wikilinks.
> 
> In the past this was not a problem because any markup in the labels
> was ignored. Now that that bug is squished, I need a way to tell
> markdown to not run the WikiLink pattern against the label. There are
> currently two mechanisms to do that. One it to set each label as an
> AtomicString. However, then we would again be back were we were with
> nested markup being ignored in labels.

Ooh, ooh!  SemiAtomicString?  ;)

> The other solution is to reorder the InlinePatterns.

I think that having patterns be order dependant isn't a great idea, in 
general.

Could the WikiLink pattern be made more context-sensitive somehow,
so that it wouldn't match if there it was inside a "Label"?

> Interestingly, it
> occurred to me that if InlinePattern was passed the parent element, we
> could test ``parent_elem.tag != 'a'``, but even then, if that
> CamelCase word is nested in strong or em tags, that test would fail.
> Besides, I can't think of any other use for doing that.

Well, if you could walk up your parents, you could check all of them for 
an 'a' (and check whether you were an attribute).  It seems like it 
might be worth defining a couple of custom walkers, to handle cases 
where we want to expand stuff, but only if it occurs in 
non-link/non-attribute places.

> Any thoughts?

It's a tough problem, to be sure.

Later,
Blake.

[Python-markdown-discuss] The WikiLinks Conundrum

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

As many of you know, the wikilink extension is not currently working.
Initially we had some problems with the way inline placeholders were
implemented but that has been resolved.

The problem is that CamelCase words that correctly appear in other
parts of the markup are mistakenly being identified as wikilinks.
Consider the following cases:

        <a href="http://example.com/">RealLink</a>
	
	<http://example.com/AutoLink>
	
 	[MarkdownLink](http://example.com/)

In all three cases, the label is identified as a wikilink and we get
nested links i.e.:

         <a href="http://example.com/"><a href="/RealLink/"
class="wikilink">RealLink</a></a>

In the past this was not a problem because any markup in the labels
was ignored. Now that that bug is squished, I need a way to tell
markdown to not run the WikiLink pattern against the label. There are
currently two mechanisms to do that. One it to set each label as an
AtomicString. However, then we would again be back were we were with
nested markup being ignored in labels.

The other solution is to reorder the InlinePatterns. The problem is,
we don't want the wikilink pattern to match against camelcase URLs
(i.e. "AutoLink" of the above autolink) so the wikilink pattern must
run after all the  various link patterns. Additionally, for various
other reasons (such as allowing asterisk in URLs) the link patterns
must be run before most other inline patterns - so we can't set the
labels as AtomicString *and* reorder either.

What this means is that, unless I'm missing something obvious, there
is no way to reliably match CamelCase wikilinks without getting nested
links when a label contains a CamelCase word. Interestingly, it
occurred to me that if InlinePattern was passed the parent element, we
could test ``parent_elem.tag != 'a'``, but even then, if that
CamelCase word is nested in strong or em tags, that test would fail.
Besides, I can't think of any other use for doing that.

Therefore, I'm thinking we will need to throw out the wikilink
extension as it currently exists. Alternatively, I could replace the
regex with a pattern that matched bracketed links (i.e. [[somelink]])
regardless of case as someone recently suggested, but then anyone
using the extension would need to update their documents to the new
syntax.

Any thoughts?

PS: If I change to [[bracketed links]], I will also change the name of
the extension to avoid any confusion. Although, probably not a drastic
change - say from "wikilink" to "wikilinks" (what it should have been
called to begin with). That way, the extension users will be forced to
note the difference and be alerted that something changed.
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Codehilite extension bug

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

On Thu, Sep 4, 2008 at 4:35 AM, Kjell Magne Fauske <kj...@gm...> wrote:
>
> There seems to be a syntax error in line 897 in the current mainline
> version of markdown.py. It should probably be changed from
>
> _prettifyETree(e)
> to
> self._prettifyETree(e)

Doh! That's what I get for failing to run the tests after the last
change I made. It's fixed now.

>
> I have also found a bug in the headerid extension. It inserts some
> strange <inline> tags in the output. I will file a ticket about this
> soon.
>
Thanks for the report.



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Codehilite extension bug

[Kjell M. F. <kj...@gm...>]

On Wed, Sep 3, 2008 at 10:22 PM, Waylan Limberg <wa...@gm...> wrote:
> Hey, just an FYI, I committed this today. Thanks for the patch.
>
> On Tue, Aug 26, 2008 at 1:38 PM, Waylan Limberg <wa...@gm...> wrote:
>> On Tue, Aug 26, 2008 at 1:23 PM, Kjell Magne Fauske <kj...@gm...> wrote:
>>>
>>> Regarding breaking css, I have filed a new ticket #16 and asked for
>>> the addition of an option for setting the name of the wrapper css
>>> class:
>>>
>>> http://www.freewisdom.org/projects/python-markdown/Tickets/000016
>>>
>>> Patch is attached, but I have probably overlooked something.
>>>
>>
>> Yeah I saw that. It looks good from a quick glance. I'll add it to my
>> list. Not sure why I didn't do that to begin with.
>>

Thank you Waylan for adding this useful feature!

There seems to be a syntax error in line 897 in the current mainline
version of markdown.py. It should probably be changed from

_prettifyETree(e)
to
self._prettifyETree(e)

I have also found a bug in the headerid extension. It inserts some
strange <inline> tags in the output. I will file a ticket about this
soon.

Regards,
Kjell Magne Fauske

Regards,
Kjell Magne Fauske

Re: [Python-markdown-discuss] Codehilite extension bug

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

Hey, just an FYI, I committed this today. Thanks for the patch.

On Tue, Aug 26, 2008 at 1:38 PM, Waylan Limberg <wa...@gm...> wrote:
> On Tue, Aug 26, 2008 at 1:23 PM, Kjell Magne Fauske <kj...@gm...> wrote:
>>
>> Regarding breaking css, I have filed a new ticket #16 and asked for
>> the addition of an option for setting the name of the wrapper css
>> class:
>>
>> http://www.freewisdom.org/projects/python-markdown/Tickets/000016
>>
>> Patch is attached, but I have probably overlooked something.
>>
>
> Yeah I saw that. It looks good from a quick glance. I'll add it to my
> list. Not sure why I didn't do that to begin with.
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] AtomicString

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

This is done [1].

Btw, if anyone is concerned that that diff removed AtomicString - it
was being defined twice for some reason so I removed one instance.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/c26816e831df0f8123cd24bd72f352f9f3909ce6

On Wed, Sep 3, 2008 at 11:31 AM, Waylan Limberg <wa...@gm...> wrote:
> On Wed, Sep 3, 2008 at 5:09 AM, Yuri Takhteyev <qar...@gm...> wrote:
>>> Therefore, I propose that we select 2 strings of random chars (using
>>> whatever method you desire) and **hardcode** those 2 strings into
>>> markdown.py. That way, on each import (each page view in the above
>>> scenario) the placeholder strings will be the same and debugging will
>>> be consistent.  What we really want is a string that will never be
>>> matched by another inline pattern's regex. We just need a string of
>>> all same-case chars between a-z of length n. As long as it does not
>>> contain any known words or abbreviations it works for me.
>>> Additionally, if the string is consistent, that makes it easier for an
>>> extension author to write  the regex for inline patterns that will not
>>> match the string in the placeholder.
>>
>> That's exactly what I suggested in my first email to this thread. :)
>>
> And that's exactly what I plan to use once I got the whitespace issues
> work out (I think I got it last night - just need a little more
> testing).
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Extra Whitespace in Output

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

On Tue, Sep 2, 2008 at 4:17 AM, Yuri Takhteyev <qar...@gm...> wrote:
>> Would anyone care if we lost all indenting and only did the linebreaks?
>
> I would guess that no.  Python Markdown 1.7 is the only implementation
> in Babelmark that does any indentation.  If we can do indentation
> right, perhaps that's an extra style point.  However, if we don't do
> the indentation at all, then we get to be like everyone else, which is
> also nice.
>

I just committed this WITHOUT indentation [1] (linebreaks only). I've
come to realize that the sample indentETree functions floating around
out there are for xml - not html which has a different take on inline
elements. I suppose someone could work off the
now-working-in-all-edge-cases-I-could-find code and add indentation to
that. But I get the feeling there will be quite a few additional
edge-cases to work out and I have more important things to work on
right now.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/a1c636a05557b1faa207828c9e7102391bdde5c9

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] AtomicString

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

On Wed, Sep 3, 2008 at 5:09 AM, Yuri Takhteyev <qar...@gm...> wrote:
>> Therefore, I propose that we select 2 strings of random chars (using
>> whatever method you desire) and **hardcode** those 2 strings into
>> markdown.py. That way, on each import (each page view in the above
>> scenario) the placeholder strings will be the same and debugging will
>> be consistent.  What we really want is a string that will never be
>> matched by another inline pattern's regex. We just need a string of
>> all same-case chars between a-z of length n. As long as it does not
>> contain any known words or abbreviations it works for me.
>> Additionally, if the string is consistent, that makes it easier for an
>> extension author to write  the regex for inline patterns that will not
>> match the string in the placeholder.
>
> That's exactly what I suggested in my first email to this thread. :)
>
And that's exactly what I plan to use once I got the whitespace issues
work out (I think I got it last night - just need a little more
testing).


-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] AtomicString

[Yuri T. <qar...@gm...>]

> Therefore, I propose that we select 2 strings of random chars (using
> whatever method you desire) and **hardcode** those 2 strings into
> markdown.py. That way, on each import (each page view in the above
> scenario) the placeholder strings will be the same and debugging will
> be consistent.  What we really want is a string that will never be
> matched by another inline pattern's regex. We just need a string of
> all same-case chars between a-z of length n. As long as it does not
> contain any known words or abbreviations it works for me.
> Additionally, if the string is consistent, that makes it easier for an
> extension author to write  the regex for inline patterns that will not
> match the string in the placeholder.

That's exactly what I suggested in my first email to this thread. :)

  - yuri


-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Extra Whitespace in Output

[Yuri T. <qar...@gm...>]

> Would anyone care if we lost all indenting and only did the linebreaks?

I would guess that no.  Python Markdown 1.7 is the only implementation
in Babelmark that does any indentation.  If we can do indentation
right, perhaps that's an extra style point.  However, if we don't do
the indentation at all, then we get to be like everyone else, which is
also nice.

  - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Extra Whitespace in Output

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

On Sun, Aug 31, 2008 at 12:27 PM, Waylan Limberg <wa...@gm...> wrote:
> On Fri, Aug 29, 2008 at 7:12 PM, Artem Yunusov <ne...@gm...> wrote:
>>
>> Yes, it's because of indentETree function. We don't have now any other
>> way of managing output, maybe in future releases ElementTree will get
>> some pretty print function, but there is no such for now. So we should
>> modify indentETree, but we shouldn't throw it away :)
>
> Yeah, I realize that now. Still getting used to ElementTree.

I have a mostly working solution [1]. There are a few weirdnesses though:

    >>> print markdown.markdown('* > bar *foo __baz__* bar\n* bar\n*
\n\t\tcode\n\n* blah')
    <ul>
      <li>
        <blockquote>
          <p>bar <em>foo <strong>baz</strong></em> bar</p>
        </blockquote>
      </li>
    <li>
        <p>bar</p>
      </li>
    <li>
        <pre><code>code
    </code></pre>
      </li>
    <li>
        <p>blah</p>
      </li>
    </ul>

Any additional <li> after the first seem to loose the level and go
back to 0. Not sure why - although the closing </li> tag seems to get
it right. There's also the weirdness to the <pre><code> tags, but this
is required because the whitespace will display in the browser
otherwise - we just have to live with it.

Here are a few other weird behaviors:

    >>> print markdown.markdown('bar *foo __baz__* bar')
    <p>bar <em>foo <strong>baz</strong></em> bar</p>

    >>> print markdown.markdown('bar *foo __baz__*')
    <p>bar <em>foo <strong>baz</strong></em>
    </p>

    >>> print markdown.markdown('*foo __baz__* bar')
    <p>
      <em>foo <strong>baz</strong></em> bar</p>

    >>> print markdown.markdown('*foo __baz__*')
    <p>
      <em>foo <strong>baz</strong></em>
    </p>

I understand why this is happening in the code, but it is weird and a
better solution isn't immediately obvious to me.

Would anyone care if we lost all indenting and only did the linebreaks?

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/5c58bec14aad3f6a1be00fa02e224e5ef3bc0f24

-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Extra Whitespace in Output

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

On Fri, Aug 29, 2008 at 7:12 PM, Artem Yunusov <ne...@gm...> wrote:
> Waylan Limberg wrote:
>> On Wed, Aug 27, 2008 at 6:16 PM, Waylan Limberg <wa...@gm...> wrote:
>>
>>>    >>> markdown.markdown('foo *bar __blah__* baz')
>>>    u'<p>foo <em>bar <strong>blah</strong>\n  </em> baz</p>'
>>>
>>> What's up with the newline and space between the closing tags
>>> ``</strong>`` & ``</em>``? Is that from the (IMO unnecessary)
>>> ``IndentTree`` function or something in
>>> ``Markdown._processPlaceholders``? I'm not sure.
>>>
>>>
>>
>> Ok, I just realized that that is the output we were getting before my
>> change to the inline placeholder. Weird! IMO that is not correct. We
>> need to loose that extra whitespace. I realize it's irrelevant in the
>> browser, but no other markdown implementation does that. Either the
>> indentTree function needs to only work on block level elements or it
>> needs to go away.
>>
>>
>
> Yes, it's because of indentETree function. We don't have now any other
> way of managing output, maybe in future releases ElementTree will get
> some pretty print function, but there is no such for now. So we should
> modify indentETree, but we shouldn't throw it away :)

Yeah, I realize that now. Still getting used to ElementTree.

> Looked at your
> placeholder branch, now extractId looks much prettier and cleaner :)

Good, then I understood how it works correctly. I'll merge it in when
I get a chance.





-- 
----
Waylan Limberg
wa...@gm...