python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] Bug report concerning tables

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

On Mon, Mar 9, 2009 at 11:59 PM, Ron Garret <ro...@fl...> wrote:
> I have not looked at the new code yet, but I have had good luck with
> the following extension for the old version:
>
> http://brian-jaress.livejournal.com/5978.html
>
> If the current code is in need of an overhaul you might want to
> consider using this as the new baseline.
>

Thanks for the link. I hadn't seen that. However, the only table
extension I'll be doing is one that copies PHP Markdown's syntax for
tables. There was just a big long discussion on the markdown list
about this and, well, it wasn't convincing. Anyway, that is one of the
great things about the extension framework; anyone can write their
own.



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

Re: [Python-markdown-discuss] Bug report concerning tables

[Ron G. <ro...@fl...>]

I have not looked at the new code yet, but I have had good luck with  
the following extension for the old version:

http://brian-jaress.livejournal.com/5978.html

If the current code is in need of an overhaul you might want to  
consider using this as the new baseline.

rg

On Mar 9, 2009, at 7:49 PM, Waylan Limberg wrote:

> On Mon, Mar 9, 2009 at 4:49 AM, Holger Rapp <Ra...@mr...> wrote:
> [snip]
>>
>> tables extension seems to replace all <p> elements with <table>...  
>> This is
>> pretty broken.
>>
>
> Thanks for the report Holger. I just pushed a fix to the repo. Turns
> out that code was pretty naive. This is the first I've looked at that
> extension very closely and I'd say the entire extension could use a
> refactor (rewritten as a blockprocessor), but at least a fix is in for
> now.
>
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

Re: [Python-markdown-discuss] Bug report concerning tables

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

On Mon, Mar 9, 2009 at 4:49 AM, Holger Rapp <Ra...@mr...> wrote:
[snip]
>
> tables extension seems to replace all <p> elements with <table>... This is
> pretty broken.
>

Thanks for the report Holger. I just pushed a fix to the repo. Turns
out that code was pretty naive. This is the first I've looked at that
extension very closely and I'd say the entire extension could use a
refactor (rewritten as a blockprocessor), but at least a fix is in for
now.

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

[Python-markdown-discuss] Bug report concerning tables

[Holger R. <Ra...@mr...>]

Yuri asked me to report this bug here. I think it is intentional, but  
this is clearly a wrong way of doing table support.

--- snip ---
The bug tracker has been fixed and I logged the bug.

Can you report it to the mailing list, though?

  - yuri

On Sun, Mar 8, 2009 at 3:34 AM, Holger Rapp <Hol...@gm...> wrote:
> didn't suceed in opening a ticket:
>
> markdown("""*This is bold*   _This too_""", extensions=["tables"])
>
> yields
> u'<table><em>This is bold</em>   <em>This too</em></table>'
>
> tables extension seems to replace all <p> elements with <table>...  
> This is
> pretty broken.
>
Regards,
Holger

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

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

On Mar 9, 2009, at 10:27 AM, Waylan Limberg wrote:

> I am pleased to announce that after much hard work, a Release
> Candidate for Python Markdown version 2.0 is now available for
> [download][]. Please, download it, install it, test it, beat it... and
> report any [bugs][]. Assuming no major bugs, we will release 2.0 final
> approximately one month from today. Until then, the project [site][]
> will continue to document version 1.7. Updated documentation is
> available in the `doc/` directory in the source files. Hopefully, all
> the included extensions will be documented before the final release.

Awesome.


>
> [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767
> [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets
> [site]: http://www.freewisdom.org/projects/python-markdown
>
> Release Notes:
> ===========
>
> * Major refactor of the core and extension API. Extension authors
> should see the included documentation in
> `docs/writing_extensions.txt`. All parts of the syntax are now
> completely overridable by extensions.
>
> * Numerous extensions added to the standard distribution (off by
> default), including an "extra" extension which matches PHP Markdown
> Extra. See the `markdown/extensions/` directory for the full list.
>
> * The code has been refactored into a full Python library with a
> separate command line script.
>
> * Optional output of XHTML1 (default) or HTML4 with the option for
> extensions to add more.
>
> * Uses ElementTree to build (X)HTML document rather than home-grown  
> NanoDom.
>
> * Most of the differences in Python-Markdown's output compared to perl
> and/or php have been eliminated.
>
> * And much more... See the changelog and [Git log][] for more details.
>
> [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs
>
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San  
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the  
> Enterprise
> -Strategies to boost innovation and cut costs with open source  
> participation
> -Receive a $600 discount off the registration fee with the source  
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss

[Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

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

I am pleased to announce that after much hard work, a Release
Candidate for Python Markdown version 2.0 is now available for
[download][]. Please, download it, install it, test it, beat it... and
report any [bugs][]. Assuming no major bugs, we will release 2.0 final
approximately one month from today. Until then, the project [site][]
will continue to document version 1.7. Updated documentation is
available in the `doc/` directory in the source files. Hopefully, all
the included extensions will be documented before the final release.

[download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767
[bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets
[site]: http://www.freewisdom.org/projects/python-markdown

Release Notes:
===========

* Major refactor of the core and extension API. Extension authors
should see the included documentation in
`docs/writing_extensions.txt`. All parts of the syntax are now
completely overridable by extensions.

* Numerous extensions added to the standard distribution (off by
default), including an "extra" extension which matches PHP Markdown
Extra. See the `markdown/extensions/` directory for the full list.

* The code has been refactored into a full Python library with a
separate command line script.

* Optional output of XHTML1 (default) or HTML4 with the option for
extensions to add more.

* Uses ElementTree to build (X)HTML document rather than home-grown NanoDom.

* Most of the differences in Python-Markdown's output compared to perl
and/or php have been eliminated.

* And much more... See the changelog and [Git log][] for more details.

[Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs

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

Re: [Python-markdown-discuss] UnicodeDecodeError

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

> Yes, I think python-markdown made the right decision. Actually I wasn't
> complaining about python-markdown but python, although maybe there's nothing
> python can do about it either, but I think it would be nice if I could just use
> the standard open function and it would figure out what the encoding of the
> file was so I didn't have to.

It's not entirely possible with perfect determinism. And even if it
was, it wouldn't solve the problem when a file has mixed encodings.

>
> I'm not sure what you can do if you have files like mine that apparently
> contains text in different encodings (I think Ron is exactly right that my file
> contained utf8 and some latin-1 characters). Can you decode that at all? You'd
> have to right code to decode it one character at a time (if that's possible)
> using utf8 and on each character catch the UnicodeDecodeError and try to decode
> the character with latin-1 instead. You'd have to have a list of all possible
> encodings in order of preference and try each encoding on each character in
> turn until you've decoded the whole file.

It's not possible since in general the "character" doesn't correspond
to the file atomic entity (the byte).
And in utf-8 characters don't have a fixed length in term of bytes.
Moreover to determine the encoding of a piece of text you need to look
at many bytes.
The only thing you can do is fix the encoding for the file (or try to
guess it in some way), and ignore or replace substrings which don't
map to the encoding.

Ciao,
Marco

>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
Marco Pantaleoni

Re: [Python-markdown-discuss] UnicodeDecodeError

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

What about doing:

fh = open(template_path, 'r')
value = fh.read()
fh.close()
value = codecs.encode(value, 'utf-8', 'replace')

?

Cheers,
Marco

On Thu, Feb 26, 2009 at 8:17 PM, tchomby <tc...@go...> wrote:
> Thanks.
>
> I don't know what encoding the files are in. They're just files that I
> created myself with a text editor, but often text has been copy-pasted
> into them from various sources, e.g. websites, and that's were the
> decoding problems occur. Presumably some non-utf8 characters get
> pasted in.
>
> I used the codecs.open trick when reading files and again when writing
> the HTML from python-markdown, wherever I was using open I replaced it
> with codecs.open. This works for most of my files but for some I get:


On Thu, Feb 26, 2009 at 8:17 PM, tchomby <tc...@go...> wrote:
> Thanks.
>
> I don't know what encoding the files are in. They're just files that I
> created myself with a text editor, but often text has been copy-pasted
> into them from various sources, e.g. websites, and that's were the
> decoding problems occur. Presumably some non-utf8 characters get
> pasted in.
>
> I used the codecs.open trick when reading files and again when writing
> the HTML from python-markdown, wherever I was using open I replaced it
> with codecs.open. This works for most of my files but for some I get:


On Thu, Feb 26, 2009 at 8:17 PM, tchomby <tc...@go...> wrote:
> Thanks.
>
> I don't know what encoding the files are in. They're just files that I
> created myself with a text editor, but often text has been copy-pasted
> into them from various sources, e.g. websites, and that's were the
> decoding problems occur. Presumably some non-utf8 characters get
> pasted in.
>
> I used the codecs.open trick when reading files and again when writing
> the HTML from python-markdown, wherever I was using open I replaced it
> with codecs.open. This works for most of my files but for some I get:
>
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xa2 in position
> 2551: unexpected code byte
>
> The error happens when I call template.substitute in this function:
>
> def render_template(template_filename,variables=None):
>    if variables is None: variables = {}
>    template_path = os.path.join('templates',template_filename)
>    template_text = codecs.open(template_path,mode='r',encoding='utf8').read()
>    template_obj = Template(template_text)
>    return template_obj.substitute(variables)
>
> So the error is no longer coming from python-markdown but from the
> standard library. Seems to be some conflict between using codecs.open
> to get a string and using Template.
>
> Fortunately this happened in few enough files that I was able to find
> and remove the offending characters manually. Still, it would be good
> to be able to read and write text from files in a robust way.
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
Marco Pantaleoni

Re: [Python-markdown-discuss] UnicodeDecodeError

[tchomby <tc...@go...>]

On Thu, Feb 26, 2009 at 02:57:16PM -0500, Waylan Limberg wrote:
> 
> Keep in mind that you just explained the various sources of your files
> earlier in your message. That particular situation is unique to you.
> Someone else will have a different situation. It is impossible for the
> markdown library to be able to anticipate every possible situation.
> Therefore, the most "robust way" is to leave the encoding/decoding to
> the end user - the only person is a position to properly address that
> specific situation.

Yes, I think python-markdown made the right decision. Actually I wasn't 
complaining about python-markdown but python, although maybe there's nothing 
python can do about it either, but I think it would be nice if I could just use 
the standard open function and it would figure out what the encoding of the 
file was so I didn't have to.

I'm not sure what you can do if you have files like mine that apparently 
contains text in different encodings (I think Ron is exactly right that my file 
contained utf8 and some latin-1 characters). Can you decode that at all? You'd 
have to right code to decode it one character at a time (if that's possible) 
using utf8 and on each character catch the UnicodeDecodeError and try to decode 
the character with latin-1 instead. You'd have to have a list of all possible 
encodings in order of preference and try each encoding on each character in 
turn until you've decoded the whole file.

Re: [Python-markdown-discuss] UnicodeDecodeError

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

On Thu, Feb 26, 2009 at 2:17 PM, tchomby <tc...@go...> wrote:
[snip]
>
> Fortunately this happened in few enough files that I was able to find
> and remove the offending characters manually. Still, it would be good
> to be able to read and write text from files in a robust way.
>

Keep in mind that you just explained the various sources of your files
earlier in your message. That particular situation is unique to you.
Someone else will have a different situation. It is impossible for the
markdown library to be able to anticipate every possible situation.
Therefore, the most "robust way" is to leave the encoding/decoding to
the end user - the only person is a position to properly address that
specific situation.

In other words, you are in a better position to know and/or determine
the encoding of your files than we or any code we write could ever
guess. Therefore, Python-Markdown's policy is to only work in Unicode.
Any encoding and/or decoding is handled by the end user. That is the
most "robust way" to handle it.

As an aside, I should note that there is an exception in that we do
handle some encoding/decoding for the command line stuff. However,
even then, it is rather dumb and requires the user to specify the
encoding for anything except utf-8 (which it expects by default).

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

Re: [Python-markdown-discuss] UnicodeDecodeError

[Ron G. <ro...@fl...>]

On Feb 26, 2009, at 11:17 AM, tchomby wrote:

> Thanks.
>
> I don't know what encoding the files are in. They're just files that I
> created myself with a text editor, but often text has been copy-pasted
> into them from various sources, e.g. websites, and that's were the
> decoding problems occur. Presumably some non-utf8 characters get
> pasted in.
>
> I used the codecs.open trick when reading files and again when writing
> the HTML from python-markdown, wherever I was using open I replaced it
> with codecs.open. This works for most of my files but for some I get:
>
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xa2 in position
> 2551: unexpected code byte

This is because you have a string that is encoded using some encoding  
other than utf-8, most likely latin-1.

You might find this example enlightening:

 >>> unicode('\xa2', 'utf-8')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa2 in position 0:  
unexpected code byte
 >>> unicode('\xa2', 'latin-1')
u'\xa2'
 >>> print _
¢
 >>> unicode('\xa2', 'latin-1').encode('utf-8')
'\xc2\xa2'
 >>> unicode('\xc2\xa2', 'utf-8')
u'\xa2'

rg

Re: [Python-markdown-discuss] UnicodeDecodeError

[tchomby <tc...@go...>]

Thanks.

I don't know what encoding the files are in. They're just files that I
created myself with a text editor, but often text has been copy-pasted
into them from various sources, e.g. websites, and that's were the
decoding problems occur. Presumably some non-utf8 characters get
pasted in.

I used the codecs.open trick when reading files and again when writing
the HTML from python-markdown, wherever I was using open I replaced it
with codecs.open. This works for most of my files but for some I get:

UnicodeDecodeError: 'utf8' codec can't decode byte 0xa2 in position
2551: unexpected code byte

The error happens when I call template.substitute in this function:

def render_template(template_filename,variables=None):
    if variables is None: variables = {}
    template_path = os.path.join('templates',template_filename)
    template_text = codecs.open(template_path,mode='r',encoding='utf8').read()
    template_obj = Template(template_text)
    return template_obj.substitute(variables)

So the error is no longer coming from python-markdown but from the
standard library. Seems to be some conflict between using codecs.open
to get a string and using Template.

Fortunately this happened in few enough files that I was able to find
and remove the offending characters manually. Still, it would be good
to be able to read and write text from files in a robust way.

Re: [Python-markdown-discuss] UnicodeDecodeError

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

Assuming your file is encoded as UTF8, you should open it with:

f = codecs.open("test.txt", mode="r", encoding="utf8")

> All this unicode stuff in python is really confusing.

Yes, it is.

- yuri

-- 
http://spu.tnik.org/

[Python-markdown-discuss] UnicodeDecodeError

[tchomby <tc...@go...>]

Can anyone tell me how to avoid this from python-markdown?

    MARKDOWN-CRITICAL: "UnicodeDecodeError: Markdown only accepts
unicode or ascii  input."

I'm reading-in text files and passing some of the contents to
python-markdown. The file contents are read into a list of strings
like this:

    f = open(path,"r")
    lines = f.readlines()

and this list of strings is later converted into one long string with
join and then passed to python-markdown like this:

    from markdown import Markdown
    md = Markdown()
    def markdown(text):
        return md.convert(text)

All this unicode stuff in python is really confusing.

Re: [Python-markdown-discuss] Announcing Micro-wiki

[Ron G. <ro...@fl...>]

On Feb 21, 2009, at 12:34 PM, Yuri Takhteyev wrote:

>> There's no authentication built in yet, so I'm a tad leery about  
>> leaving a
>> public demo running.
>
> Actually, the main missing feature is revision control, if you ask me.
> A wiki can still be useful without authentication, but a wiki without
> revision control cannot be of any practical use, IMHO.
>
> What is your goal? Are you looking to build something that could be
> used as a wiki in practice? If so, I am guessing it won't stay <100
> LOC for long. One can do a basic wiki in <100 LOC (actually, one can
> do that in just 5), but I don't believe one can do a practical wiki in
> under 500.
>
> I went through all of this with Sputnik over the past year and a half.
> It started with the goal of being small, 1000 LOC written in one
> evening, but then there is always one next feature that people can't
> live without. You need authentication, you need permissions, you need
> configuration, etc. I had to redefine "small" as meaning "small
> relative to what it can do". :)

At this point it's more of an exercise than anything else.  But the  
long-term goal is to have a wiki written in Python to be part of a  
larger system.  I tried MoinMoin and Trac and neither one met my needs.

Architecturally the goal is to make it as modular as possible.  If you  
look at the source code you will see that the filestore is already  
separated.  The interface is just a dictionary, and in fact you can  
stick a Python dictionary in place of the fdict objects and it will  
work.  (You will lose all the state as soon as you quit the process,  
so this is only good for testing and demo purposes.)  I have a modular  
authentication system all ready to plug in as well, but that currently  
relies on MySQL and I wanted to minimize dependencies in the first  
release.

I agree that revision control is crucial, I just haven't settled on a  
design yet.  In particular, I haven't decided whether on not to punt  
on conflict resolution, which is a whole can o' worms in an of itself.

My plan was to add a MySQL storage engine, and then use that for  
revision control.  I could also extend fdicts to keep track of  
revisions.  As long as you're willing to punt on conflict resolution  
(which for small groups I think is not an unreasonable tradeoff) it  
can stay pretty simple.

rg

Re: [Python-markdown-discuss] Announcing Micro-wiki

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

> There's no authentication built in yet, so I'm a tad leery about leaving a
> public demo running.

Actually, the main missing feature is revision control, if you ask me.
A wiki can still be useful without authentication, but a wiki without
revision control cannot be of any practical use, IMHO.

What is your goal? Are you looking to build something that could be
used as a wiki in practice? If so, I am guessing it won't stay <100
LOC for long. One can do a basic wiki in <100 LOC (actually, one can
do that in just 5), but I don't believe one can do a practical wiki in
under 500.

I went through all of this with Sputnik over the past year and a half.
It started with the goal of being small, 1000 LOC written in one
evening, but then there is always one next feature that people can't
live without. You need authentication, you need permissions, you need
configuration, etc. I had to redefine "small" as meaning "small
relative to what it can do". :)

- yuri

-- 
http://spu.tnik.org/

Re: [Python-markdown-discuss] Announcing Micro-wiki

[Ron G. <ro...@fl...>]

On Feb 21, 2009, at 10:52 AM, Yuri Takhteyev wrote:

> Sounds like fun! Can you put up a demo online and perhaps add more
> documentation?

There's no authentication built in yet, so I'm a tad leery about  
leaving a public demo running.  It's a pretty big security hole.  But  
it takes literally less than a minute to get it up and running on your  
system.  Download, unpack, run driver.py, and point a browser at  
localhost:8080.  There are (or at least should be) no external  
dependencies other than Python.

> Does the wiki use markdown.py and showdown in combination, or does the
> user choose between the two?

It uses markdown on the back-end and showdown to provide a live update  
as you edit.  It's really pretty cool.

rg

Re: [Python-markdown-discuss] Announcing Micro-wiki

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

Sounds like fun! Can you put up a demo online and perhaps add more
documentation?

Does the wiki use markdown.py and showdown in combination, or does the
user choose between the two?

 - yuri

On Sat, Feb 21, 2009 at 10:27 AM, Ron Garret <ro...@fl...> wrote:
> Gents,
> I've written a small experimental wiki called µWiki (pronounced micro-wiki)
> that uses code that you've written: markdown.py, showdown, Yaro and
> Selector.  The wiki itself is only about 100 LOC.  More information can be
> found here:
> http://www.flownet.com/ron/code/uwiki.html
> This is an alpha-test version.  Any comments, feedback or suggestions any of
> you may have would be much appreciated.
> Thanks,
> Ron Garret
> ro...@fl...
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



-- 
http://spu.tnik.org/

[Python-markdown-discuss] Announcing Micro-wiki

[Ron G. <ro...@fl...>]

Gents,

I've written a small experimental wiki called µWiki (pronounced micro- 
wiki) that uses code that you've written: markdown.py, showdown, Yaro  
and Selector.  The wiki itself is only about 100 LOC.  More  
information can be found here:

http://www.flownet.com/ron/code/uwiki.html

This is an alpha-test version.  Any comments, feedback or suggestions  
any of you may have would be much appreciated.

Thanks,
Ron Garret
ro...@fl...

Re: [Python-markdown-discuss] WikiLinks

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

On Fri, Feb 13, 2009 at 8:47 PM, Ron Garret <ro...@fl...> wrote:
> I realize I'm a little late to the party, but is there a reason you
> didn't just construct an RE that matched CamelCase outside of links,
> and then run that at the very end?

Well, when the inline patterns are run, the document is an ElementTree
Object. In other works, the html markup is not part of the text - so
no that won't work. An to complicate matters, ElementTree Objects
don't keep a reference to their parent - so we can't just check the
parent.

However, I suppose there isn't any reason why someone couldn't write a
post-processor which did something like this. Although, it'll be fun
getting it to ignore codeblocks and various other edge cases. That's
the thing about CamelCase links. There's always going to be false
positives. I've gotten the sense over the years that pretty much any
serious system which has started out with them has either regretted it
or abandoned them for this reason. But, for some situations, people
like them, so if someone wants to write an extension, they are more
than welcome.


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

Re: [Python-markdown-discuss] WikiLinks

[Ron G. <ro...@fl...>]

I realize I'm a little late to the party, but is there a reason you  
didn't just construct an RE that matched CamelCase outside of links,  
and then run that at the very end?

This nearly works:

 >>> re1 = re.compile(r'(?:<a .+?>.+?</a>.*?)*\b((?:[A-Z]+[a-z-_]+) 
{2,})\b')
 >>> re1.findall('<a href=ThisWontMatch>NeitherWillThis</a>ButThisWill')
['ButThisWill']

It falsely matches embedded CamelCase at the end of a string:

 >>> re1.findall('<a href=ThisWillMatchButItShouldnt>SoWillThis</a>')
['ThisWillMatchButItShouldnt', 'SoWillThis']

You can hack around this by appending a sentinal CamelCase string at  
the end to generate an extraneous match, and then just ignore that  
match.  (There's probably a way to fix the RE to do the Right Thing  
but I'm not such a studly RE hacker.)

rg


On Feb 11, 2009, at 9:21 PM, Waylan Limberg wrote:

> On Wed, Feb 11, 2009 at 10:34 PM, Yuri Takhteyev  
> <qar...@gm...> wrote:
>>> OK, thanks.  Is there any projection on when 2.0 will be released?
>>
>> Good question. Do we have any outstanding issues? I had a plan of
>> changing all the processors from run() to __call__(), but I've given
>> up on this plan since. So, unless we have any specific bugs, we  
>> should
>> just release it.
>>
>
> I have two things on my list. Unfortunately, I haven't had time to
> work on anything lately. I have a solution for both (in my head), I
> just haven't implemented them yet. Once I do, I'll let everyone know.
>
> In case your wondering, the two items are:
> 1. Lists currently only nest one level with the new core -
> interestingly no tests were checking deeper than that so I didn't
> catch it right way. This is a *must have* IMO, so we need to wait for
> this before releasing. If ElementTree Elements had references to their
> parents this would be *a lot* easier. While I'm at it, I also have one
> minor change to the API for the blockprocessors in mind - so this
> needs to happen before we lock into 2.0.
>
> 2. The fenced_code_block extension needs some cleanup per discussion
> on the markdown list. This is a pretty simple adjustment to the regex
> and should be easy enough. Nice to have, but probably not a
> show-stopper.
>
> There is also some more documentation work to do. The important stuff
> is documented in the source and up-to-date (we'll copy it to the wiki
> when we release), but some of the extensions need their documentation
> updated (such as the new wikilinks ext). Again, not a show stopper. If
> someone wants to help out, patches are welcome adding docs for each
> extension to the repo based on what is currently in the wiki.
>
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg

Re: [Python-markdown-discuss] WikiLinks

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

On Wed, Feb 11, 2009 at 10:34 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> OK, thanks.  Is there any projection on when 2.0 will be released?
>
> Good question. Do we have any outstanding issues? I had a plan of
> changing all the processors from run() to __call__(), but I've given
> up on this plan since. So, unless we have any specific bugs, we should
> just release it.
>

I have two things on my list. Unfortunately, I haven't had time to
work on anything lately. I have a solution for both (in my head), I
just haven't implemented them yet. Once I do, I'll let everyone know.

In case your wondering, the two items are:
1. Lists currently only nest one level with the new core -
interestingly no tests were checking deeper than that so I didn't
catch it right way. This is a *must have* IMO, so we need to wait for
this before releasing. If ElementTree Elements had references to their
parents this would be *a lot* easier. While I'm at it, I also have one
minor change to the API for the blockprocessors in mind - so this
needs to happen before we lock into 2.0.

2. The fenced_code_block extension needs some cleanup per discussion
on the markdown list. This is a pretty simple adjustment to the regex
and should be easy enough. Nice to have, but probably not a
show-stopper.

There is also some more documentation work to do. The important stuff
is documented in the source and up-to-date (we'll copy it to the wiki
when we release), but some of the extensions need their documentation
updated (such as the new wikilinks ext). Again, not a show stopper. If
someone wants to help out, patches are welcome adding docs for each
extension to the repo based on what is currently in the wiki.

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

Re: [Python-markdown-discuss] WikiLinks

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

> OK, thanks.  Is there any projection on when 2.0 will be released?

Good question. Do we have any outstanding issues? I had a plan of
changing all the processors from run() to __call__(), but I've given
up on this plan since. So, unless we have any specific bugs, we should
just release it.

  - yuri

-- 
http://spu.tnik.org/

Re: [Python-markdown-discuss] WikiLinks

[Ron G. <ro...@fl...>]

OK, thanks.  Is there any projection on when 2.0 will be released?

rg

On Feb 11, 2009, at 7:02 PM, Waylan Limberg wrote:

> The old "wikilink" (note no "s") has been abandoned and a new
> "wikilinks" extension has replaced it. The new extension uses
> ``[[bracketed links]]`` rather than ``CamelCase`` links. There are
> various reasons why, which were discussed in the archives.
>
> The difference is documented in the source code, but no where else
> yet. Of course, when we release 2.0, the website will be updated.
> Until then, the website will continue to document 1.7.
>
> The old 1.7 version can be found here in the repo:
>
> http://gitorious.org/projects/python-markdown/repos/mainline/blobs/bcc437814eb90c60120d0e7a9c1ece85bf66aea3/mdx_wikilink.py
>
> or http://tinyurl.com/c5kb7t
>
> On Wed, Feb 11, 2009 at 8:12 PM, Ron Garret <ro...@fl...> wrote:
>> Hi,
>>
>> What is the current state of the wikilinks extension?  I've tried to
>> get it to work with both 1.7 and 2.0 without success.  In 2.0 the
>> extension seems to load OK, but it doesn't actually work:
>>
>> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
>> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>> Type "help", "copyright", "credits" or "license" for more  
>> information.
>>>>> import markdown
>>>>> markdown.markdown('# Test\nWikiLinkTest', ['wikilinks'])
>> u'<h1>Test</h1>\n<p>WikiLinkTest</p>'
>>>>> markdown.version_info
>> (2, 0, 0, 'beta-2')
>>
>> Am I doing something wrong, or are wikilinks known to not be working?
>>
>> Thanks,
>> rg
>>
>>
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with  
>> Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills  
>> and code to
>> build responsive, highly engaging applications that combine the  
>> power of local
>> resources and data with the reach of the web. Download the Adobe  
>> AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> -- 
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg

Re: [Python-markdown-discuss] WikiLinks

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

The old "wikilink" (note no "s") has been abandoned and a new
"wikilinks" extension has replaced it. The new extension uses
``[[bracketed links]]`` rather than ``CamelCase`` links. There are
various reasons why, which were discussed in the archives.

The difference is documented in the source code, but no where else
yet. Of course, when we release 2.0, the website will be updated.
Until then, the website will continue to document 1.7.

The old 1.7 version can be found here in the repo:

http://gitorious.org/projects/python-markdown/repos/mainline/blobs/bcc437814eb90c60120d0e7a9c1ece85bf66aea3/mdx_wikilink.py

or http://tinyurl.com/c5kb7t

On Wed, Feb 11, 2009 at 8:12 PM, Ron Garret <ro...@fl...> wrote:
> Hi,
>
> What is the current state of the wikilinks extension?  I've tried to
> get it to work with both 1.7 and 2.0 without success.  In 2.0 the
> extension seems to load OK, but it doesn't actually work:
>
> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import markdown
>  >>> markdown.markdown('# Test\nWikiLinkTest', ['wikilinks'])
> u'<h1>Test</h1>\n<p>WikiLinkTest</p>'
>  >>> markdown.version_info
> (2, 0, 0, 'beta-2')
>
> Am I doing something wrong, or are wikilinks known to not be working?
>
> Thanks,
> rg
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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