Customising HTML output in SuperRedcloth?

I have been using the technique outlined in this post by Geoffrey
Grosenbach to extend RedCloth to output customised HTML markup.

http://nubyonrails.com/articles/about-this-blog-custom-textile

With the newer builds of the RedCloth gem, I’m using v3.290, this
technique doesn’t seem to work:

Using RedCloth version 3.274

require ‘RedCloth’
=> true

class YellowCloth < RedCloth
def textile_ruby( tag, atts, cite, content )
%(

#{content}
)
end
end
=> nil

YellowCloth.new(‘ruby. def blah()’).to_html
=> ”

ruby. def blah()

”

(This example is taken from one of the comments on Geoffrey’s post.)

I’m assuming that this is because the latest version is a significant
rewrite of RedCloth and isn’t as easily extensible in the same way?

If so, does anyone know of an alternate technique to extend the latest
version to output customised HTML markup?

You can customize the HTML markup it outputs by opening the
RedCloth::HTML class and overriding the method you want to change.
The article describes defining new patterns, though, and since
RedCloth is now using Ragel to look for patterns, it can’t be
extended at this point. If you come up with a way that it could be,
though, please submit a patch!

In lieu of editing RedCloth, you could extend it and then add a
wrapper or method chain that would first parse and transform your
custom patterns and pass the result to RedCloth. This RedCloth
version is much better about not mangling HTML than previous versions.

Jason G. wrote:

You can customize the HTML markup it outputs by opening the
RedCloth::HTML class and overriding the method you want to change.
The article describes defining new patterns, though, and since
RedCloth is now using Ragel to look for patterns, it can’t be
extended at this point. If you come up with a way that it could be,
though, please submit a patch!

In lieu of editing RedCloth, you could extend it and then add a
wrapper or method chain that would first parse and transform your
custom patterns and pass the result to RedCloth. This RedCloth
version is much better about not mangling HTML than previous versions.

Thanks Jason,

Your idea of pre-formatting the custom patterns before passing it off to
RedCloth is very smart. Perhaps this is even preferable to trying to
override RedCloth itself. The beauty of Textile is that you can drop
down into HTML when the need arises, so it makes sense to send RedCloth
a mixture of standard textile markup and more “special” HTML and just
let RedCloth do its thing.

I’d be interested if someone does come up with a way of customising
RedCloth’s HTML output (I’m no Ragel expert, so it won’t be me!), but in
the mean time I’m going to experiment with pre-parsing my custom markup
into HTML before sending it to RedCloth.

Good stuff!

On Mon, 2008-04-14 at 23:42 +0200, James King wrote:

custom patterns and pass the result to RedCloth. This RedCloth
version is much better about not mangling HTML than previous versions.

Thanks Jason,

I think a number of people are exploiting the ability to patch in their
own extra commands. It would probably worth clearly documenting this
significant architectural change when the release is out just to make it
clear to others.

Your idea of pre-formatting the custom patterns before passing it off to
RedCloth is very smart. Perhaps this is even preferable to trying to
override RedCloth itself. The beauty of Textile is that you can drop
down into HTML when the need arises, so it makes sense to send RedCloth
a mixture of standard textile markup and more “special” HTML and just
let RedCloth do its thing.

Again, I want to do something similar. I’m writing a publishing system
for a few personal projects, and like Jason suggested, I’m using a
wrapper method to do any custom processing either before or after. While
it might be obvious to some, you might want to be aware of a few points:

if you want to have custom block elements, you probably want to process
these before sending to RedCloth (rather than after). This way any
content inside the block item is escaped properly by the respective
formatter (whether it be escaping HTML entities, or escaping things like
back slashes in you are using LaTeX).

Inline elements probably want to be done afterwards, as you probably
don’t have formatter escaping issues.

I think there is a tag. You can wrap this round block
elements before sending to RedCloth if you have preprocessed the content
and don’t want RedCloth to accidentally interpret something if it
clashes.