As mentioned, the issue here is catastrophic backtracking on that huge data string. I think addressing this in the general case may be a bit difficult (with the obvious solution being not to shove that much code into a single block), since unfortunately we're playing with fire here.
That said, in this particular scenario Markdown shoots itself in the foot a ...
I think this is a good idea. I don't have to explain what the advantages would be; the question covers that enough, I think. There are two things I'd like to do with the answer: giving an optional design and discussing the developer's pain to create this.
It could look like this (I used the Electrical Engineering site for these images):
As you ...
This is the reason you can see the markdown view if the rendered view is confusing. The <2-> doesn't show up in the rendered before view because it's unescaped, so the browser reads it as a tag. It shows up in the after view because the edit made it part of a code block. The rendered view is generally easier to understand, but the markdown view lets ...
Most of this has been done for a while now; the only thing missing was inferring the highlighting language when you're writing/editing a question and editing its tags.
This final part will be working after the next build.
Fixed in the next build. We recently* tightened up restrictions on the API's JSONP callback parameter (mostly in response to this). Unfortunately we broke ourselves with that, because when retrieving the question title to show it in the preview we used a callback of the form apiCallbacks["meta.stackexchange.com"], which the new restrictions don't allow ...
The link parser allowed too much whitespace in the URL, thus creating this:
The auto-linker saw "http://..." following a newline, and dutifully turned it into a link.
<a href="\n<a href="http://link">http://link</a>">Invalid</a>
Along came the HTML sanitizer, which takes everything ...
The code block for the test.py file contained a very long string literal
going on with some nonzero entries for a while, then ending in an estimated 80KB of \x00. All on one line.
That led to the parsing of the code block taking unusually long.
When that post was created, our Markdown parser ignored the numbers and always started new lists at 1. That has since changed, but the post has never been re-rendered to reflect that change, so it is still showing a cached copy of how it was rendered at the time it was posted.
If you simply make some completely frivolous change so that the system caches a ...
The preview just guesses what language you're using based on keywords. After it's posted, the highlighting is tag-based.
The erlang tag has no highlighting enabled because Prettify doesn't have an Erlang mode. Your counterexample actually has shell-script highlighting because of the sh tag.
You can manually specify the language if you think the results ...
Look at the timestamp on that answer:
edited Jul 28 '09 at 12:45
The HTML that is displayed on a question page is only rendered once, at submission, and not everytime it's viewed. So the answer you see is what the Markdown engine created almost four years ago. Lots of changes have been made to both Markdown engines since then.
When you click "edit", you ...
Good thing I tested this out in a separate browser. :)
Used your regex with a small modification to preserve leading spaces that we currently allow in front of horizontal rules. The fix will go out with the next prod build. Thanks!
It's a mindful suggestion, but the comment system need not be convoluted further. And, like @Bart pointed out in the comments, you have the five minute period after submitting a comment to edit it, which should be more than enough time to fix broken links, spelling/grammar, and markdown errors. The 600 character limit on comments is such that comments will ...
An alternate solution I would suggest is making the preview scrollable once it reaches a certain size. This way you can see the same part of the post in both the preview and editor, regardless of the length of your answer.
An extra spiffy feature would be to auto-scroll the preview along with the editor, so as you change where you are in one, the other ...
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 ...
We consider the preview to be somewhat mandatory. We have enough horribly formatted posts already where new users ignore the preview. Condoning or encouraging this is the last thing we want to do.
The only reason that button exists is that when inline editing a post, there may be interesting content below the editor. This is not the case otherwise. And in ...
As a work around, you can use either the full form or footnote styles of anchors:
Either of them will ...
_This is a test_
Here's what I'm typing to get this result:
\_This is a test\_
To use reserved characters in their literal form, simply escape them with a backslash. For an '*', I simply escape it:
\* <-- Escaped asterisk
Until a recent change to the tag ...
This wasn't even really a new bug – this was always broken:
You may be right <!-- http://xkcd.com/386 --> about this.
You may be right http://xkcd.com/386 --> about this.
because the auto-linker did this:
You may be right <!-- <a href="http://xkcd.com/386">http://xkcd.com/386</a> --> about this.
and the ...
I totally agree with this. As an example, here is a diagram I've posted Preventing FIN_WAIT2 when closing socket about the TCP connection states.
It would be very practical to be able to click on the image to read the text correctly. I'm not sure all users are very familiar with the r-click > View image process.
So having a magnify icon in the corner ...
The problem isn't so much that you put the closing </pre> tag on a new line, but rather that you have two sets of <pre> blocks with stuff in them, and you didn't write them in a way that the parser was hoping you would.
Essentially, what happens is that there's a set of regular expressions that attempt to temporarily remove raw HTML from the ...
This is close to impossible to get really right, but I have a userscript that tries to come as close as possible: Dude, where's my cursor?.
It comes with a few caveats, so be sure to read the description.
There's already a "hide preview" link when editing, at least for the regular edits:
According to some comments, this is missing when using suggested edits though, or when not using the inline editing for some other reason.
Turns out the markdown editor relied on some stuff in the old top-bar to find out whether this feature should be enabled or not on a given site. And since the old top-bar is no more, it's disabled, always (just on the site(s) / meta.SO where the new top-bar is enabled)
Fix in meta rev 2013.11.15.1646 (proof ^^). Thanks for reporting that.
Provided the width of the preview is not reduced to accommodate a scroll bar (an inaccurate preview would be worse than an annoying one), I would very much like to see this improvement. There does not need to be a height to the preview - it can extend indefinitely downwards as it does now, allowing standard scrolling of the whole webpage which people ...