In 1.7.24 I’ve added Ruby and Ruby on Rails as a language on Crayon. Even cooler, I’ve added the <% ... %> and similar delimiter tags for eRuby/RHTML. Using Multiple Language Highlighting in Crayon, you can choose HTML as the base language with the lang="html" attribute or the [html]...[/html] Mini Tag and then through in some eRuby syntax. The red bits are Ruby, all else is XHTML. Note you can do the same thing with PHP tags, CSS tags and JavaScript tags.

Here’s the shortcode I used:

[html]
Some <strong>HTML</strong> first.

<ul style="color:red;">
<% 3.times do %>

  <li>list item</li>

<% end %>

% $s("ewfwe")

</ul>

<%= "print something" %>

Tada.
[/html]

Here’s some Ruby:

And the shortcode:

$[rb toolbar="always"]
def create_set_and_get(initial_value=0) # Note the default value of 0
  closure_value = initial_value
  return Proc.new {|x| closure_value = x}, Proc.new { closure_value }
end

setter, getter = create_set_and_get  # ie. returns two values
setter.call(21)
getter.call # => 21

#You can also use a parameter variable as a binding for the closure.
#So the above can be rewritten as...

def create_set_and_get(closure_value=0)
  return proc {|x| closure_value = x } , proc { closure_value }
end

proc {|arg| print arg}
Proc.new {|arg| print arg}
lambda {|arg| print arg}

# introduced in Ruby 1.9
->(arg) {print arg}

# In an object instance variable (denoted with '@'), remember a block.
def remember(&a_block)
  @block = a_block
end

# Invoke the above method, giving it a block which takes a name.
remember {|name| puts "Hello, #{name}!"}

# When the time is right (for the object) -- call the closure!
@block.call("Jon")
# => "Hello, Jon!"

[/rb]

Some themes use a page template containing a custom loop. The issue is:

Since your theme uses a page to load a totally different query from the page it visits there’s no way for Crayon to know what you’re going to request until it reads your has_posts() request. By that time, the header is already written so there’s no chance to enqueue themes and fonts that you’ve used in your Crayons. Fortunately I’ve added a feature so that they are embedded each time if needed. This is a bit more inefficient I think, but it works by adding the required css right before each Crayon. This issue won’t occur on any other page on the site because direct links to pages and posts containing Crayons will load just fine with enqueuing, which is why the other pages worked for you.

The solution is added in 1.7.17 and 1.7.19. 1.7.17 now uses the the_posts filter by default (again) rather than the wp action which checks just the main wp query. The setting that fixes the issue is this:

It basically turns off enqueuing and prints the css in front of Crayon’s whenever it encounters a page. Posts will continue to enqueue themes in the head as usual.