search

zcaudate-me / lein-midje-doc

moved -> 'lucid.publish'
http://docs.caudate.me/lucidity/lucid-publish.html
73 stars 8 forks source link

Let 'plain' option actually produce plain output. #2

Closed xsc closed 11 years ago

xsc commented 11 years ago

As discussed in #1, this pull request fixes the handling of the command line option plain (and the subsequent use of the affected var *plain*). I'll have a look at escaping the contents of the <pre> blocks if you want to. Should be possible with something like:

(clojure.string/escape "<title>" { \< "&lt;" \> "&gt;" \& "&amp;" })
;; => "&lt;title&gt;"

That would remove most problematic cases, I guess.

zcaudate commented 11 years ago

Thanks mate! Really appreciate your help!

xsc commented 11 years ago

Always happy to help!

zcaudate commented 11 years ago

Hmmm... this <pre> rendering business is tough.... I've run plain on the document and half of it is not rendering properly. I wonder if for now, its better to take away this option completely

xsc commented 11 years ago

Did you try including the clojure.string/replace call (in the *plain* case, obviously) I posted in the text of this pull request above? I'd be surprised if that didn't at least get us closer to a solution.

If you don't have the time, I can try it myself, of course. :)

zcaudate commented 11 years ago

Hey Yannick!

I've added you to the GitHub so free to push into the lib. I'm a bit behind on work atm so any help is greatly appreciated :)

On 05/10/2013, at 23:10, Yannick Scherer notifications@github.com wrote:

Did you try including the clojure.string/replace call (in the plain case, obviously) I posted in the text of this pull request above? I'd be surprised if that didn't at least get us closer to a solution.

If you don't have the time, I can try it myself, of course. :)

— Reply to this email directly or view it on GitHub.

xsc commented 11 years ago

Thank you very much! I implemented basic HTML escaping in this commit. Since this is not the most critical of issues I'll not merge into master until you've reviewed the changes.

Good luck with your work and have a nice day!

zcaudate commented 11 years ago

Btw. Off topic.

Is there a way for rewrite-clj to output the line number of the element it is currently on. I've seen it there when the parser comes across an error but i'm not sure of the function call that does this.

This will be very useful for tagging code in the readmes.

On 06/10/2013, at 0:42, Yannick Scherer notifications@github.com wrote:

Thank you very much! I implemented basic HTML escaping in this commit. Since this is not the most critical of issues I'll not merge into master until you've reviewed the changes.

Good luck with your work and have a nice day!

— Reply to this email directly or view it on GitHub.

zcaudate commented 11 years ago

Hey Yannick!

I've had a look and it's good to commit. It's really good to have another on the code. Luckily for me, you're also more careful with details than I am :)

On 06/10/2013, at 0:42, Yannick Scherer notifications@github.com wrote:

Thank you very much! I implemented basic HTML escaping in this commit. Since this is not the most critical of issues I'll not merge into master until you've reviewed the changes.

Good luck with your work and have a nice day!

— Reply to this email directly or view it on GitHub.

xsc commented 11 years ago

Luckily for me, you're also more careful with details than I am :)

Am I though? (Looking at you, namespaced keywords...)

Is there a way for rewrite-clj to output the line number of the element it is currently on.

The information is there at parsing time but the only way to generate it afterwards (currently) is by counting the :newline nodes. I'll think of something.

I've had a look and it's good to commit.

Very well, merging initiated. :)

zcaudate commented 11 years ago

Hahaha... Well you did get the rest of the language :)

I tried a number of parsers before rewrite-clj - they were all too complicated. I even tried to write my own instaparser and it was the slowest parser I had ever seen...

On 07/10/2013, at 18:23, Yannick Scherer notifications@github.com wrote:

Luckily for me, you're also more careful with details than I am :)

Am I though? (Looking at you, namespaced keywords...)

Is there a way for rewrite-clj to output the line number of the element it is currently on.

The information is there at parsing time but the only way to generate it afterwards (currently) is by counting the :newline nodes. I'll think of something.

I've had a look and it's good to commit.

Very well, merging initiated. :)

— Reply to this email directly or view it on GitHub.