The following formatting causes the preview output to differ from the actual output. It contains the text <$fh>. The preview displays the <$fh> while it does not display in the actual post. While the wiki text in use is weird, the preview should never differ from the end result.


$content = do { local $/; };

This was noticed in this post.

A lot of people are going to say its poor formatting, which it is! That is not the issue. The issue is the preview and result differ which should never happen.

  • 4
    It does in your post. It shows in the post you linked as well. Can you include a screenshot, and browser and OS details? Dec 18, 2012 at 21:24
  • @MartijnPieters I got the formatting wrong, didn't noticed the <pre> tags involved. I just updated it, could you look again? Also let me link to the correct revision of that original post... done.
    – Schwern
    Dec 18, 2012 at 21:27

3 Answers 3


As you know, part of this is user error. If you follow the guidelines for using block-level HTML, the preview and the rendered view will appear the same. Taking your code as an example and properly aligning the <pre> elements:

   $content = do { local $/; <$fh> };

...gives you:


   $content = do { local $/;  };

Since the <pre> elements are not properly aligned in your case, both Markdown parsers fail to recognise the raw HTML block and substitute it out. As a result, the usual Markdown conversions are run on the text, including the one that selectively swaps in &lt; for <.

The swapping is done with the same regular expression in MarkdownSharp and PageDown:


...which shouldn't match your <$, allowing it to be stripped later by the HTML sanitizer. In PageDown's case though, your $ has already been replaced in preprocessing by ~D to avoid unintended submatch substitutions as the input text makes its way through the various Markdown matchers.

Since <~ does match the aforementioned expression, the preview swaps &lt; in for <, and the sanitizer allows the rendered <$fh> through in the preview, which accounts for the discrepancy.

The easiest fix for PageDown in this case is likely to account for the $ substitution in the angle replacement regular expression, in the form of:


Alternatively, $ characters could be escaped appropriately in all replacement strings, but this could require changes in a number of places.

From the user perspective, the easiest course of action is to either follow the indentation rule as it applies to raw block HTML, or to just use normal Markdown code blocks.

  • Thank you very much for taking the time to look into it.
    – Schwern
    Dec 19, 2012 at 20:43

What Tim said. Not doing the ~D substitution and instead escaping dollar characters in regex replacements would be bound for a new set of headaches, in particular since Safari, including the Mobile versions, has an absolutely broken handling of dollars when they are returned from replacement functions, so those would have to be handled as well.

Anyway, fix is made; this will be in the next build.

  • Thanks for the explanation and thanks for the fix!
    – Schwern
    Dec 19, 2012 at 20:42

Your post doesn't include a newline. Using <pre> does not magically escape other markup.

If you use proper markdown the <pre> tags are not needed at all; simply add a newline after the install.pl line:


       $content = do { local $/; <$fh> };

renders properly as:


      $content = do { local $/; <$fh> };
  • 1
    Thank you. Formatting IS horrible and wrong, agreed. The issue is the preview and the final result differ.
    – Schwern
    Dec 18, 2012 at 21:33
  • @Schwern: The preview is just that, a preview. It is not always correct, as it uses the browser facilities. Sometimes the browser result is different. Dec 18, 2012 at 21:36
  • Unless I'm mistaken, this is how one reports bugs on SO?
    – Schwern
    Dec 18, 2012 at 21:38
  • @Schwern: It indeed is; I see balpha (SE dev) does work on preview bugs. The editor is an external component IIRC. Dec 18, 2012 at 21:42
  • Great! Thanks. Just want to make sure its valid and it will get seen.
    – Schwern
    Dec 18, 2012 at 22:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .