What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 130 Stack Exchange communities.

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.


install.pl


$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.

share|improve this question
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? –  Martijn Pieters Dec 18 '12 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 '12 at 21:27

3 Answers 3

up vote 3 down vote accepted

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:

install.pl
<pre>    
   $content = do { local $/; <$fh> };
</pre>

...gives you:

install.pl

    
   $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:

<(?![A-Za-z/?\$!])

...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:

<(?![A-Za-z/?!]|~D)

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.

share|improve this answer
    
Thank you very much for taking the time to look into it. –  Schwern Dec 19 '12 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.

share|improve this answer
    
Thanks for the explanation and thanks for the fix! –  Schwern Dec 19 '12 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:

install.pl

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

renders properly as:

install.pl

      $content = do { local $/; <$fh> };
share|improve this answer
1  
Thank you. Formatting IS horrible and wrong, agreed. The issue is the preview and the final result differ. –  Schwern Dec 18 '12 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. –  Martijn Pieters Dec 18 '12 at 21:36
    
Unless I'm mistaken, this is how one reports bugs on SO? –  Schwern Dec 18 '12 at 21:38
    
@Schwern: It indeed is; I see balpha (SE dev) does work on preview bugs. The editor is an external component IIRC. –  Martijn Pieters Dec 18 '12 at 21:42
    
Great! Thanks. Just want to make sure its valid and it will get seen. –  Schwern Dec 18 '12 at 22:22

You must log in to answer this question.

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