python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] Looking for advices to write a markdown plugin

[Alexandre L. <new...@al...>]

Hello Yuri,

thanks a lot for your interest.
I think it would be more like separators, as I don't have the need to 
exclude certain parts from being commented.

Best,

Alex

On 02/17/2010 07:43 PM, Yuri Takhteyev wrote:
> In particular, do you see §s as separators breaking up your input into
> chunks, or do you see them as labels that get attached to natural HTML
> units (paragraphs, list items, etc.) marking them as commentable?
>    

Re: [Python-markdown-discuss] Looking for advices to write a markdown plugin

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

> However it gets more complex with other HTML elements such as lists,
> headers etc.
>
> Do you have any idea on how I could implement such a syntax?

I'll be happy to offer suggestions on the implementation, but right
now I am not quite sure what you want to achieve. What do you want
your output to look like? Do you want the parser to insert divs based
on where it finds §s? What do you _want_ it to do with lists, etc?

In particular, do you see §s as separators breaking up your input into
chunks, or do you see them as labels that get attached to natural HTML
units (paragraphs, list items, etc.) marking them as commentable?

  - yuri

[Python-markdown-discuss] Looking for advices to write a markdown plugin

[Alexandre L. <new...@al...>]

Hello,

I wrote a simple text-publishing Django application enabling per 
paragraph comments. It splits a texts into chunks and let people comment 
them. The project is hosted at http://github.com/aleray/close-commenting 
and a demo is visible there: 
http://closecommenting.stdin.fr/one-possible-scenario-for-a-collective-future.html

It uses markdown in its back-end to format the texts and right now they 
are split according to their first level HTML tags (see 
http://github.com/aleray/close-commenting/blob/master/closecommenting/models.py 
line 93)

I'm looking for writing a markdown extensions that would allow one to 
arbitrary tell the parser semantic units to comment on instead of 
relying on the document structure. For instance, in some case it might 
make more sens to comment two <p/> together, or to have two comments in 
one <p/>.

A quick fix is to enclose units in <div/> but it is not very elegant. My 
first idea was to make a proper syntax was to add a "§" glyph to 
indicate a commentable section. eg.

§ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas 
hendrerit mattis faucibus. Vivamus auctor sollicitudin urna, et 
fringilla purus auctor id. Duis laoreet feugiat magna, ac consequat 
lectus sagittis vitae.
§ Phasellus non egestas urna. Morbi eget lacus felis. Vivamus molestie 
est quis diam feugiat ac faucibus justo vulputate. Mauris sed lectus 
arcu. Fusce euismod suscipit ligula a convallis.
§ ...

or 2 paragraphs together

§ Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas 
hendrerit mattis faucibus. Vivamus auctor sollicitudin urna, et 
fringilla purus auctor id. Duis laoreet feugiat magna, ac consequat 
lectus sagittis vitae.
§ Phasellus non egestas urna. Morbi eget lacus felis. Vivamus molestie 
est quis diam feugiat ac faucibus justo vulputate. Mauris sed lectus 
arcu. Fusce euismod suscipit ligula a convallis. Donec iaculis augue sit 
amet magna tempor at auctor tellus vehicula. Maecenas ac leo justo. 
Phasellus laoreet hendrerit mauris, vitae scelerisque justo sollicitudin 
sed. Etiam molestie sodales leo at feugiat. In hac habitasse platea 
dictumst. Pellentesque at enim sed ante mollis fermentum. Donec quis 
enim dictum nibh fermentum imperdiet.

Nullam urna orci, iaculis non porttitor at, ultricies dictum metus. 
Quisque viverra lacus eu ante viverra blandit. Etiam tempor, ante ac 
tincidunt lobortis, arcu risus fringilla justo, non tempus velit nisl 
fermentum erat. Etiam semper, sapien sed condimentum elementum, magna 
neque viverra dolor, blandit suscipit arcu mauris porta lorem. Nulla 
orci massa, ultrices ut congue nec, pretium aliquam tortor. Donec 
imperdiet laoreet purus ac luctus. Sed sit amet ante tellus, at sodales 
metus. Praesent scelerisque, sem ut porta rutrum, lorem ante ornare 
diam, pharetra feugiat orci odio id nisl. Praesent imperdiet pharetra 
pulvinar. Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
Quisque lobortis sollicitudin placerat. Maecenas ut pharetra purus. 
Maecenas sit amet magna ac dui euismod accumsan ac id ligula. Curabitur 
sit amet lorem non purus vehicula mollis accumsan at tellus. Maecenas 
consectetur posuere laoreet. Quisque risus leo, iaculis sit amet aliquam 
ac, ultricies sed lectus. Nam non libero ligula. Nullam volutpat 
tincidunt tortor non venenatis. Nam ultricies lacus a leo porta 
tincidunt fringilla quam hendrerit. In imperdiet imperdiet nibh, a 
bibendum erat interdum in.

§ ...

However it gets more complex with other HTML elements such as lists, 
headers etc.

Do you have any idea on how I could implement such a syntax?

Best,

Alexandre Leray

[Python-markdown-discuss] Proposal: Switching tests to nose

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

I'd like to propose that we switch all testing to use the nose testing
framework [1]. Almost two years ago I first broached this subject, but
there was a lot of unanswered questions and unresolved issues. Today,
that is no longer the case IMO. I have pushed a branch [2] which has
fully integrated all the existing tests into nose. I suggest reading
the documentation [3] for a full rundown of how everything works.

[1]: http://somethingaboutorange.com/mrl/projects/nose/
[2]: http://gitorious.org/python-markdown/mainline/commits/tests
[3]: http://gitorious.org/python-markdown/mainline/blobs/tests/docs/test_suite.txt

Oh, and the branch currently has one failing test which I purposely
left failing to show what the output looks like. Go ahead and play
with it.

There are a few reasons why I want to do this.

(1). The existing framework provided no way to run the UnitTests and
DocTests which have been added over the last couple years. Nose
discovers and runs these tests automatically. We are starting to see
more extensions developed by the community. Those UnitTests are
necessary to make sure we don't break other peoples extensions - so we
need to be running them regularly.

(2). Any time a new set of settings are required for a test, the
actual code for our testing framework needs to be edited. Currently,
safe_mode and output_format are defined explicitly, while extensions
are defined by the directory name. And there is no way to pass in or
test different sets of config options for extensions.

(3). It is currently not easy to run tests from other implementations
through our existing framework. If we want to match perl/php
implementations, we should be able to run their tests.

(4). I have found it very annoying that each test dir generates a
separate html report - especially when many extensions only contain
one test each. Why can't all the tests from all dirs be written to one
file? I'm also not crazy about how the existing html reports are
formatted. Why aren't the results inline with the list of tests
(instead of at the bottom) and why aren't we using unified diffs?

(5). I've come across a few bugs recently that the existing framework
doesn't even allow us to check for. For example, the current framework
does some weird stuff with leading whitespace that hid the problem
reported in [ticket 44].

[ticket 44]: http://www.freewisdom.org/projects/python-markdown/Tickets/000044

Now, I realize the existing framework could be refactored to address
all of these issues, but is was actually less work to make nose give
us everything we already have and more. What I have in the branch
addresses every one of the above issues. And, as each txt/html file
pair is in it's own UnitTest, each is sandboxed from the rest.

Plus, we can use things like nose's coverage plugin (which, btw,
indicates that some areas of Markdown are seriously undertested). We
can only run tests that failed (or passed) on the last run. We can run
any small subset of tests at a time. All these things come with no
work from us. Nose gives it to us for free. We lose nothing and have
much to gain.

Still not convinced? Go check out this [video] of a Pycon 2009 Panel:
"Functional Testing Tools in Python". A question asked at 46:19
sparked a little rant about projects that implement their own testing
frameworks. Some valid arguments are provided. These are the guys who
write the testing frameworks. They say we should leave the code that
runs tests to them. After putting together the nose plugins that make
nose work for us, I have to agree. I'd rather maintain those two
plugins than have to continue maintaining our own framework.

[video]: http://blip.tv/file/1947342

Personally, I'm likely to use this from now on. Even if this doesn't
get into the master branch, I will continue to develop on my tests
branch and cherrypick commits to merge back to master. Obviously, I'd
rather not need to do the cherrypicking.

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

[Python-markdown-discuss] Fwd: WikiLinks extension

[Peter H. <pjr...@gm...>]

Sorry, failure to use "reply to all"....


---------- Forwarded message ----------
From: Peter Harley <pjr...@gm...>
Date: 2010/1/13
Subject: Re: [Python-markdown-discuss] WikiLinks extension
To: Waylan Limberg <wa...@gm...>


2010/1/13 Waylan Limberg <wa...@gm...>:
> On Tue, Jan 12, 2010 at 7:57 PM, Yuri Takhteyev <qar...@gm...> wrote:
> That being the case, [text](/link) seems better to me than
> [[link|text]]. Interestingly, both use the exact same number of
> characters - so wikilinks are not even a shortcut here. The one
> exception would be if you were using the extensions option to
> automatically append a path to the wikilink.
>
>> I think if one wants to build a wiki using Markdown, [[link|title]] is
>> really the way to go and Peter's patch does add value to Wikilinks.
>>
>
> Maybe the problem is my aversion to wikilinks in general (yes, I know
> I wrote the original extension - every time we get a feature request
> for it I wish I hadn't). When we already have an easy way to define
> links (using Markdown), the only value, IMO, of wikilinks is to
> eliminate the need to separately define a label when the label is the
> same as the link text. Isn't that the whole point of wikilinks to
> begin with? Adding the option to define labels on wikilinks is just a
> replication of an existing feature we already have. It might be
> different if we didn't have that other option.
>
> Regardless, if you think its a good idea and want to commit Peter's
> patch, I can live with it. But he asked if we were interested.
> Personally, I'm not.

As you say, it was only a suggestion and I'm not really bothered either way.

The real reason I was fiddling about in the first place is that I'm
using the wikilinks extension with django to get urls for blog posts
from their slugs, so I don't have to hard code links into my posts.
The piping syntax was just me getting sidetracked!

Anyway, its not really hard to do if anyone else wanted it anyway.
It's only a few lines.
I've stuck it on dpaste if you want to have a look.

http://dpaste.com/hold/144513/

Peter

Re: [Python-markdown-discuss] WikiLinks extension

[Tom I. <to...@je...>]

On Wed, Jan 13, 2010 at 1:57 AM, Yuri Takhteyev <qar...@gm...> wrote:
> The alternatives you suggested don't really work. [[link]](text) is
> the _opposite_ of standard markdown, which would be [text](link). Same
> for [/link](text).

Philosophically speaking (uh oh) is the text inside a Wikilink the
link, that just happens to be used as the title of the page? Or is it
the title of the page that the web server 'coincidentally' uses as
part of the link to that page? Because if it's the latter, [[MyPage]]
is a page title with a default server-assigned URL, and [[some link
here]](MyPage) would be a more markdown-y way of explicitly specifying
the link rather than deriving it from the title.

Tom Insam
to...@je...

Re: [Python-markdown-discuss] WikiLinks extension

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

On Tue, Jan 12, 2010 at 7:57 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Seeing that Markdown already has a simple syntax for creating labels
>> for links, I'm not sure this offers any value. And, if something of
>> the sort was added, I would think it should use the already
>> established syntax of markdown. So perhaps: ``[[ALink]](click here)``.
>> But you might as well just do ``[/ALink](click here)`` with the
>> existing non-wikilink syntax.
>
> I disagree. Furthermore, I had to do the exact same change as Peter
> suggested for the Lua markdown, because I wanted precisely that
> feature.
>
> For better or worse, the WikiLinks extension already breaks with
> standard Markdown and it makes sense to build on how it already works.
>
> The alternatives you suggested don't really work. [[link]](text) is
> the _opposite_ of standard markdown, which would be [text](link). Same
> for [/link](text).

Whoops, got my () and [] mixed up. Sorry. Guess I responded a little
to quickly there.

> We could try doing something like [text](\link), but this would also
> be quite confusing, since the syntax for wikilink with custom title
> would be totally different form the basic wikilink.

Ok, let me try this again, with the correct syntax this time. In
markdown, the first thing you come to is the label for a link. The
actual link comes after. This happens to be easier for reading - which
fits into the markdown philosophy IMO.

That being the case, [text](/link) seems better to me than
[[link|text]]. Interestingly, both use the exact same number of
characters - so wikilinks are not even a shortcut here. The one
exception would be if you were using the extensions option to
automatically append a path to the wikilink.

> I think if one wants to build a wiki using Markdown, [[link|title]] is
> really the way to go and Peter's patch does add value to Wikilinks.
>

Maybe the problem is my aversion to wikilinks in general (yes, I know
I wrote the original extension - every time we get a feature request
for it I wish I hadn't). When we already have an easy way to define
links (using Markdown), the only value, IMO, of wikilinks is to
eliminate the need to separately define a label when the label is the
same as the link text. Isn't that the whole point of wikilinks to
begin with? Adding the option to define labels on wikilinks is just a
replication of an existing feature we already have. It might be
different if we didn't have that other option.

Regardless, if you think its a good idea and want to commit Peter's
patch, I can live with it. But he asked if we were interested.
Personally, I'm not.


P.S. Yes that means that any wiki I would develop would not support
wikilinks of any kind if it was up to me alone. I originally wrote the
extension as an easy proof of concept to learn how the extension API
worked. Once I got the basics worker out I moved on to more complex
things and didn't come back to the extension until it became part of
Markdown and needed to be updated for the API improvements for 2.0.

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

Re: [Python-markdown-discuss] WikiLinks extension

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

> Seeing that Markdown already has a simple syntax for creating labels
> for links, I'm not sure this offers any value. And, if something of
> the sort was added, I would think it should use the already
> established syntax of markdown. So perhaps: ``[[ALink]](click here)``.
> But you might as well just do ``[/ALink](click here)`` with the
> existing non-wikilink syntax.

I disagree. Furthermore, I had to do the exact same change as Peter
suggested for the Lua markdown, because I wanted precisely that
feature.

For better or worse, the WikiLinks extension already breaks with
standard Markdown and it makes sense to build on how it already works.

The alternatives you suggested don't really work. [[link]](text) is
the _opposite_ of standard markdown, which would be [text](link). Same
for [/link](text).

We could try doing something like [text](\link), but this would also
be quite confusing, since the syntax for wikilink with custom title
would be totally different form the basic wikilink.

I think if one wants to build a wiki using Markdown, [[link|title]] is
really the way to go and Peter's patch does add value to Wikilinks.

- yuri

Re: [Python-markdown-discuss] WikiLinks extension

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

On Tue, Jan 12, 2010 at 5:13 PM, Peter Harley <pjr...@gm...> wrote:
> Hi all,
>
> I've written a patch that changes the Wikilinks extension to accept piped
> links a la wikipedia, so [[ALink|click here]] will produce a link with the
> text "click here". I'm a bit of a git newbie, so I have a simple patch, but
> I can't figure out how to submit a merge request.
>
> Anyway, just wondering if there was interest in including something like
> this.
>

Seeing that Markdown already has a simple syntax for creating labels
for links, I'm not sure this offers any value. And, if something of
the sort was added, I would think it should use the already
established syntax of markdown. So perhaps: ``[[ALink]](click here)``.
But you might as well just do ``[/ALink](click here)`` with the
existing non-wikilink syntax.

So no, I'm not interested. Of course, anyone can use there own
extensions which define their own syntax. Perhaps you could publish it
somewhere and add a link on the wiki [1] for others to find and use if
they so choose. If it turns out to be popular, we could always add it
later.

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

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

[Python-markdown-discuss] WikiLinks extension

[Peter H. <pjr...@gm...>]

Hi all,

I've written a patch that changes the Wikilinks extension to accept piped
links a la wikipedia, so [[ALink|click here]] will produce a link with the
text "click here". I'm a bit of a git newbie, so I have a simple patch, but
I can't figure out how to submit a merge request.

Anyway, just wondering if there was interest in including something like
this.

Peter

Re: [Python-markdown-discuss] ImageLinks Ext broken (was: <p> tag missing from list items + ImageLinks)

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

> I guess this is a long way around saying I'm inclined to simply remove
> it. Obviously, it doesn't work for anyone so no one should miss it.
> However, if someone else wanted to fix it, I wouldn't be against
> merging their changes in either.

I agree.

 - yuri

Re: [Python-markdown-discuss] ImageLinks Ext broken (was: <p> tag missing from list items + ImageLinks)

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

On Sun, Jan 10, 2010 at 10:00 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Looks to me like url_manager is some third party module for someone's
>> blog app. With a quick glance, it appears it's just building the path
>> for each image and the thumbnail path.
>
> That someone would be me.
>
> I don't remember for sure, but this might have been the original
> Markdown extension, which I checked in (probably ~2006) as an example.
> I.e., you could never use it directly since it was hooked into my blog
> code (which I released at some point too, but it's not worth looking
> for), but it would give you an example of how to write an extension. I
> am pretty sure that for a while there were just two extensions - this
> one and footnotes.
>
> Now that we have no shortage of examples, perhaps we should delete it.
> Or, someone could fix it.
>

Ah, well that explains things - including why there has never been any
tests for it.

Given the proliferation of javascript libraries (i.e.: JQuery plugins)
that can create nice galleries given a list of photos, I'm not so sure
this extension is of much value. Although, being that I never used it,
I don't know what its output looked like. Perhaps a simple extension
that listed all photos in a given directory for use by these modern
gallery libs would be sufficient.

While automated dir walking is nice, I think I'd prefer to just add
the images manually to a markdown document. That certainly avoids the
issues involved in working out paths and such in code. And given that
I recently added the ability to have markdown text inside any
arbitrary raw html block (via markdown=1 attribute like php does), you
could even wrap your list in an appropriate block with a class or id
set for your javascript to work off of. In addition this wouldn't tie
you to any specific js library. Write you own raw html to fit the lib
your using. Much better that trying to write an extension that works
with many libs and their varying APIs.

I guess this is a long way around saying I'm inclined to simply remove
it. Obviously, it doesn't work for anyone so no one should miss it.
However, if someone else wanted to fix it, I wouldn't be against
merging their changes in either.

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

Re: [Python-markdown-discuss] ImageLinks Ext broken (was: <p> tag missing from list items + ImageLinks)

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

> Looks to me like url_manager is some third party module for someone's
> blog app. With a quick glance, it appears it's just building the path
> for each image and the thumbnail path.

That someone would be me.

I don't remember for sure, but this might have been the original
Markdown extension, which I checked in (probably ~2006) as an example.
I.e., you could never use it directly since it was hooked into my blog
code (which I released at some point too, but it's not worth looking
for), but it would give you an example of how to write an extension. I
am pretty sure that for a while there were just two extensions - this
one and footnotes.

Now that we have no shortage of examples, perhaps we should delete it.
Or, someone could fix it.

  - yuri

[Python-markdown-discuss] ImageLinks Ext broken (was: <p> tag missing from list items + ImageLinks)

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

Anyone know anything about the ImageLinks extension?

On Fri, Jan 8, 2010 at 3:56 PM, Ilpo Ilves <ilp...@ho...> wrote:
>> From: wa...@gm...
>> Date: Fri, 8 Jan 2010 14:14:54 -0500
>>
>> On Fri, Jan 8, 2010 at 1:53 PM, Ilpo Ilves <ilp...@ho...> wrote:
>> > I was trying to get ImageLinks extension to work. However, the website
>> > does
>> > not mention the name of the extension. I've tried to enable ImageLinks
>> > extension using 'image_links', 'imagelinks', 'imagelink' and
>> > 'image_link',
>> > with no luck (Python Markdown gives a warning).
>>
>> It should be 'imagelinks' (all lower case). If that's not working then
>> we have a problem.
>
> I tried that again, and I can't get ImageLinks extension to load.
>

So it appears that the Imagelinks Extension is failing in import. I've
never used or worked on the extension personally, and I'm not sure of
the history of the extension. Anyway, the problem seems to be that it
is trying to import a non-existent module 'url_manager'. The only
place the module is used directly is line 41:

        url = url_manager.BlogEntryUrl(url_manager.BlogUrl("all"),
                                       "2006/08/29/the_rest_of_our")

Looks to me like url_manager is some third party module for someone's
blog app. With a quick glance, it appears it's just building the path
for each image and the thumbnail path.

Anyone have any info on this?

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

Re: [Python-markdown-discuss] <p> tag missing from list items + ImageLinks

[Ilpo I. <ilp...@ho...>]

> From: wa...@gm...
> Date: Fri, 8 Jan 2010 14:14:54 -0500
> 
> On Fri, Jan 8, 2010 at 1:53 PM, Ilpo Ilves <ilp...@ho...> wrote:
> > Hi,
> >
> > Here seems to be a bug in Python Markdown:
> >
> > When looking at the .html output, some list items <li> are surrounded by <p>
> > tags, and some are not. I'm not sure what causes this. However, this leads
> > to problems when styling the .html with a .css file.
> 
> I would suggest you go read the syntax docs for lists [1] very
> carefully. Especially the part towards the end about multiple
> paragraphs. It should be more clear why it is acting the way it does.
> If you still think we're not following the syntax correctly, used
> babelmark [2] to compare our output to others (particularly perl and
> php). If you do find a specific instance were python-markdown gets it
> wrong, then please do report back.
> 
> [1]: http://daringfireball.net/projects/markdown/syntax#list
> [2]: http://babelmark.bobtfish.net/

Thanks, this was the cause. Python Markdown acts correctly.

> > I was trying to get ImageLinks extension to work. However, the website does
> > not mention the name of the extension. I've tried to enable ImageLinks
> > extension using 'image_links', 'imagelinks', 'imagelink' and 'image_link',
> > with no luck (Python Markdown gives a warning).
> 
> It should be 'imagelinks' (all lower case). If that's not working then
> we have a problem.

I tried that again, and I can't get ImageLinks extension to load.

Kalle Rutanen

 		 	   		  
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010

[Python-markdown-discuss] <p> tag missing from list items + ImageLinks

[Ilpo I. <ilp...@ho...>]

Hi,

Here seems to be a bug in Python Markdown:

When looking at the .html output, some list items <li> are surrounded by <p> tags, and some are not. I'm not sure what causes this. However, this leads to problems when styling the .html with a .css file.

I was trying to get ImageLinks extension to work. However, the website does not mention the name of the extension. I've tried to enable ImageLinks extension using 'image_links', 'imagelinks', 'imagelink' and 'image_link', with no luck (Python Markdown gives a warning).

Good work with Python Markdown thus far!

Kalle Rutanen

 		 	   		  
_________________________________________________________________
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010

Re: [Python-markdown-discuss] markdown + codehilite + pygments

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

Hi Ian,

On Wed, Nov 25, 2009 at 6:35 PM, Ian Stokes-Rees
<ijs...@cr...> wrote:
> I have the latest version of python markdown and pygments installed,
> however I'm not getting any luck with the codehilite extension.
> pygmentize from the command line works fine, import pygments works from
> the Python interpreter, and otherwise markdown works fine both from the
> command line and from my mod_python apache httpd output filter.
>
> I have in my test file:
>
> :::python
> for a in list:
>    b = 42
>    c = [1,2,3]
>    c.sort()
>    pass
> sys.exit()
>
> s1.xcfg:
> :::xml
> <simple1
>   foo="bar"
>   zip="zap"
> />
>

Are your code blocks indented at least four spaces? I notice they are
not in the above example.

What output are you getting?

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

[Python-markdown-discuss] markdown + codehilite + pygments

[Ian Stokes-R. <ijs...@cr...>]

I have the latest version of python markdown and pygments installed, 
however I'm not getting any luck with the codehilite extension.   
pygmentize from the command line works fine, import pygments works from 
the Python interpreter, and otherwise markdown works fine both from the 
command line and from my mod_python apache httpd output filter.

I have in my test file:

:::python
for a in list:
    b = 42
    c = [1,2,3]
    c.sort()
    pass
sys.exit()

s1.xcfg:
:::xml
<simple1
   foo="bar"
   zip="zap"
/>

and to render this I do in python (s is the string of the file):

markdown.markdown(s, ['codehilite'])

or:

$ markdown -x codehilite xconfig.md

In both cases it down't produce any pygments formatted output.  I have 
also tried #!python.

Any suggstions what I might be doing wrong?

Thanks,

Ian

-- 
Ian Stokes-Rees                            W: http://sbgrid.org
ijs...@cr...               T: +1 617 432-5608 x75
SBGrid, Harvard Medical School             F: +1 617 432-5600

Re: [Python-markdown-discuss] Python 2.3 support

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

On Sun, Oct 25, 2009 at 11:43 AM, Yuri Takhteyev <qar...@gm...> wrote:
>> Just an FYI, Django has officially dropped support for Python 2.3 in
>> their still-in-development version 1.2. [1]
>
> If Django is dropping support for Python 2.3, I think we can do the same.
>
> Perhaps we could do two things for the benefit of current or future
> python 2.3 users:
>
> 1. Make a branch in gitorious of the last version known to work with
> 2.3 This would help if someone needs to fix bugs in it later.
>
> 2. Make a page on the wiki pointing to the last release known to work
> with python 2.3 and to the gitorious branch known to work with it.

I agree on both counts. I'll do that when I get a chance - unless you
beat me to it.


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

Re: [Python-markdown-discuss] Python 2.3 support

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

> Just an FYI, Django has officially dropped support for Python 2.3 in
> their still-in-development version 1.2. [1]

If Django is dropping support for Python 2.3, I think we can do the same.

Perhaps we could do two things for the benefit of current or future
python 2.3 users:

1. Make a branch in gitorious of the last version known to work with
2.3 This would help if someone needs to fix bugs in it later.

2. Make a page on the wiki pointing to the last release known to work
with python 2.3 and to the gitorious branch known to work with it.

  - yuri

[Python-markdown-discuss] Python 2.3 support

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

Just an FYI, Django has officially dropped support for Python 2.3 in
their still-in-development version 1.2. [1]

I realize we won't do so 'just because they did,' but if a large
project like that can confidently drop support, then a small project
like this probably can as well.

Oh, and all those resent complaints about the install script not
working on older versions of Python were all for 2.4. I didn't hear
one thing from anyone running 2.3. I suspect that at this point,
people still using 2.3 are not upgrading packages.

Unless there are any objects to the contrary, I'm inclined to at least
stop testing in 2.3. Any thoughts?

[1]: http://code.djangoproject.com/changeset/11640

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

Re: [Python-markdown-discuss] [Plone-Users] ZopeSkel version pinning invalid

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

> Oh, I should state that I am only stating my personal views on
> setuptools here. I do not know Yuri's position and will use whatever
> he prefers.

I am not sure if it really matters what my position is, given my
recent lack of involvement with this project. But what it's worth, I
agree with Waylan that we do not want our default installation scripts
to assume setuptools. Defining the version number in two places is a
small price to pay for avoiding this additional dependency.

  - yuri

Re: [Python-markdown-discuss] [Plone-Users] ZopeSkel version pinning invalid

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

Oh, I should state that I am only stating my personal views on
setuptools here. I do not know Yuri's position and will use whatever
he prefers.

This was simply an attempt to explain why I did what I did.

On Sun, Oct 11, 2009 at 11:07 AM, Waylan Limberg <wa...@gm...> wrote:
> First, sorry for not responding directly to this message. As I've
> stated elsewhere, my connectivity has been very limited these past few
> weeks and probably will be for the next couple months. My normal dev
> box for this stuff is currently disassembled and in storage - making
> proper testing in all supported versions less than ideal. Like many
> open source projects, I do this in my spare time and sometimes life
> gets in the way.
>
> Second, I will add that while setuptools certainly has it's merits, I
> personally do not care for it and would prefer to not use it at all.
> For more specifics from someone smarter than me, I would suggest
> reading Ian Bicking's thoughts (among others) on setuptools (the
> creator of pip and virtualenv). Of course, at the same time I realize
> that others actually use easy_install regularly (including markdown
> users) so I make sure it works.
>
> However, that's about as far as I prefer to go. I saw your patch
> switched to using setuptools and I stopped reading. I could suggest
> that if someone provides a patch that allows use of various extended
> features of setuptools we would use it, but the fact is, I don't want
> to maintain it.
>

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

Re: [Python-markdown-discuss] [Plone-Users] ZopeSkel version pinning invalid

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

First, sorry for not responding directly to this message. As I've
stated elsewhere, my connectivity has been very limited these past few
weeks and probably will be for the next couple months. My normal dev
box for this stuff is currently disassembled and in storage - making
proper testing in all supported versions less than ideal. Like many
open source projects, I do this in my spare time and sometimes life
gets in the way.

Second, I will add that while setuptools certainly has it's merits, I
personally do not care for it and would prefer to not use it at all.
For more specifics from someone smarter than me, I would suggest
reading Ian Bicking's thoughts (among others) on setuptools (the
creator of pip and virtualenv). Of course, at the same time I realize
that others actually use easy_install regularly (including markdown
users) so I make sure it works.

However, that's about as far as I prefer to go. I saw your patch
switched to using setuptools and I stopped reading. I could suggest
that if someone provides a patch that allows use of various extended
features of setuptools we would use it, but the fact is, I don't want
to maintain it.

Anyway, enough about me...

On Sun, Oct 11, 2009 at 5:41 AM, kiorky <ki...@cr...> wrote:
> Hi,
>
> The problem is fixed although the solution used is far for optimal and even
> dirty for me:
>
>        * Duplication around current version, my pkg_resources call in the proposed
> patch was not there to make things nicer,

I'm not crazy about the version number being defined in two places
either. However, the fact is, that is how it was for some time - even
before I joined the project. I more recently fixed that, but the
dependency on ElemenTree was added even later. In fact, this is the
first time this project has had any third party dependencies - so
we're still ironing out a few things. I suppose it doesn't help that
non of the core devs use older python versions that don't have
ElementTree in the standard lib. We just test on an install of those
versions which already have the dependency installed.

> Think that if you want to use that,
> you can't import the module with version bites in the setup.py because at
> install time, your distribution will not be already registered with the
> setuptools machinery and you will get some DistributionNotFoundError unless you
> had a previous markdown installation (silent error).
>
>        * False commit messages
>                """
>                Fixed a silly bug in setup.py. Importing version from the lib
>                requires that all dependencaies for the lib are present, so we
>                can't actuly import the lib until after we check for
>                dependencies - which means we can't import version in the setup
>                script. Grrr. We'll have to remember to update the version
>                number in both places from now on. Sigh.
>                """
>        It's not true [1]. The real problem, i think was an ImportError  at install
> time (ElementTree?) resulting on an unavailability of the module. That was one
> of the purposes of my provided patch also...

Exactly, the ImportError was from tying to import ElementTree, which
failed because it was not installed yet. Obviously, the setup script
can't import a module before it installs it - which was what my commit
message was trying to convey in a roundabout sort of way.

If someone can provide a better patch that doesn't use setuptools,
I'll happily commit it.

Oh, and my comment regarding the "silly error" was in regard to
myself. It was silly of me to not recognize the potential for that
error to occur.

>        * Another error is to mixing setuptools and distutils, AFAIK, install_requires
> is on setuptools side.

Not true. As part of a previous bug report, someone provided a patch
that used install_requires and that was my initial thought. But then I
checked the distutils docs and there is was, albeit, not documented
very well.

I should also point out that our documentation recommends that anyone
on <2.5 run `easy_install elementtree` before `easy_install markdown`.
That seems "good enough" for me. However, I realize that that may not
be ideal for mass deployments across numerous systems using some
automated mechanism - which is more likely the situation were people
are stuck using those aging python versions.

As as aside Ian Bicking's pip offers a much nicer solution to this problem IMO.

> That may be why Waylan did not spoil me this new release.
>

Sorry, I don't follow your point with the rest of your message. It
appears to be an attempt to impress me with the magic of setuptools.
But that's the thing, too much magic isn't always better. Again, see
pip for a less magical approach. If I misunderstood your intent,
apologize.

Regardless, we appreciate your feedback.

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

Re: [Python-markdown-discuss] [Plone-Users] ZopeSkel version pinning invalid

[kiorky <ki...@cr...>]

Hi,

The problem is fixed although the solution used is far for optimal and even
dirty for me:

	* Duplication around current version, my pkg_resources call in the proposed
patch was not there to make things nicer, Think that if you want to use that,
you can't import the module with version bites in the setup.py because at
install time, your distribution will not be already registered with the
setuptools machinery and you will get some DistributionNotFoundError unless you
had a previous markdown installation (silent error).

	* False commit messages
		"""
		Fixed a silly bug in setup.py. Importing version from the lib
		requires that all dependencaies for the lib are present, so we
		can't actuly import the lib until after we check for
		dependencies - which means we can't import version in the setup
		script. Grrr. We'll have to remember to update the version
		number in both places from now on. Sigh.
		"""
	It's not true [1]. The real problem, i think was an ImportError  at install
time (ElementTree?) resulting on an unavailability of the module. That was one
of the purposes of my provided patch also...

	* Another error is to mixing setuptools and distutils, AFAIK, install_requires
is on setuptools side.


That may be why Waylan did not spoil me this new release.

[1] See how i can import things there and there.

(m)kiorky@judith ~/test $ tree
|-- mylib
|   |-- __init__.py
|   |-- version.py
`-- setup.py


(m)kiorky@judith ~/test $ cat setup.py
#!/usr/bin/env python

__docformat__ = 'restructuredtext en'

from setuptools import setup, find_packages
from mylib.version import version

setup(
    name = 'mylib',
    version = version,
    packages = find_packages(),
    include_package_data=True,
    install_requires=["zc.buildout"],
)

# vim:set et sts=4 ts=4 tw=80:
(m)kiorky@judith ~/test $ cat mylib/version.py
version='1.0'

---------> sdist does not complain about mylib.version call

(m)kiorky@judith ~/test $ python setup.py sdist
running sdist
tar -cf dist/mylib-1.0.tar mylib-1.0
gzip -f9 dist/mylib-1.0.tar
removing 'mylib-1.0' (and everything under it)

----------> neither setuptools (Distribute there)

(m)kiorky@judith ~/test $ easy_install  -U dist/mylib-1.0.tar.gz
...
Installed /home/kiorky/m/lib/python2.4/site-packages/mylib-1.0-py2.4.egg
...
Installed /home/kiorky/m/lib/python2.4/site-packages/zc.buildout-1.4.1-py2.4.egg
...
Finished processing dependencies for mylib==1.0

(m)kiorky@judith ~/test $ python -c "from mylib.version import version;print
version"
1.0



Yuri Takhteyev a écrit :
> Waylan released a new version (2.0.3) a few days ago. Did this fix the problem?
> 
> - yuri
-- 
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF