13

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


11

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. The design It could look like this (I used the Electrical Engineering site for these images): As you ...


8

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


8

This bug has been fixed in Markdig, the server-side Markdown renderer we're using. I just updated the version we use to the one including the bugfix for this specific issue. Moving forward, you should see a proper level-2 heading in blockquotes with the syntax you gave in your example.


7

We don't support syntax highlighting in the profile. If you want to make a case for why we should, a feature request would be fine. I'll see about turning the preview off (thanks for pointing that out, Patrick!) to match the server-side behaviour.


7

The code block for the test.py file contained a very long string literal data="\x01\x00\x00\x00\x70\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02... 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.


7

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


7

An equal sign (=) under a line means header formatting in Markdown (see Markdown Help). You need to remove the =) at the bottom of your "About Me", it'll go back to normal. Although the preview is still showing something that is different from what it looks like when you visit your profile, so it's still a bug.


6

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


6

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


6

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!


6

Smells like a version of this bug to me (thanks Glorfindel for digging it up), though I'm not totally sure. I submitted this to the DAG team's bug triage process and will report back.


6

A fix for this is rolling out with build rev 2020.1.8.35735. The bug here was a regression from when we switched default URLs from http to https. The server-side code that detects question URLs had to consider both cases (http and https), but was relying on a default parameter value for the http case instead of explicitly probing for it (site.Url() instead ...


5

_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


5

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


5

As a work around, you can use either the full form or footnote styles of anchors: [http://read.pudn.com/downloads99/sourcecode/windows/bitmap/406853/doors.cpp__.htm](http://read.pudn.com/downloads99/sourcecode/windows/bitmap/406853/doors.cpp__.htm) [http://read.pudn.com/downloads99/sourcecode/windows/bitmap/406853/doors.cpp__.htm][1] Either of them will ...


5

The fix will be in the next production build.


4

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.


4

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.


4

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.


4

I've tweaked and added to ˈjuː.zɚ79365's version of a side-by-side editing script from Mathematics.SE to make it work again. It's in a userscript format. Side by Side editing @ Stack Apps For more information and an installation link, please visit my Stack Apps post :) This script does not, unlike Discourse, have autoscroll, and does not preserve the ...


4

For me the current editor and preview are enough. I do understand you won't be a markdown master from the start, but you don't need to. The toolbar helps you to learn the markdown language, and even if you don't learn the syntax, still the preview will show you what the end result was. You seem to be asking for a WYSIWYG editor. There is no added value for ...


4

There is an option called asteriskIntraWordEmphasis in Markdown.Converter.js which needs to be set to enable the intra-word emphasis. You pass the options when creating the converter object, so you can enable it by doing something like this: var converter = new Markdown.Converter({asteriskIntraWordEmphasis: true}); I just tested this using the demo and it ...


4

Thanks for highlighting this. We're using different renderers for the preview and for rendering Markdown content server-side and both use their own, built-in mechanism to detect links. Ideally, both would behave exactly the same. Unfortunately they don't quite match perfectly all the time. I've got a bugfix about to go out that's trying to make both ...


4

However, I noticed that there are more differences in the rendered version and the one generated by CommonMark which is the reason that I am raising this as a bug, so the developers can take a look at it if they are not aware of it yet. All those are expected: We avoid breaking existing posts by erring on the side of safety. If a post looks different using ...


3

Tag wiki excerpts can't contain Markdown or links - just plain text. Therefore there is nothing to "preview". What you are typing is what you will get. Tag wiki bodies follow the same rules as questions and answers.


3

Odd as it might seem, this is very much by design, I think. A Markdown list item needs content to be recognized as such. Without content, it's just an odd/unspecified continuation of the previous line. Even more: most Markdown implementations handle it like this. You can see for yourself on the Babelmark Markdown Testbed. (Note that it's not just the preview;...


3

Fixed in the next build. The preview and rendered version still aren't 100% consistent in some broken cases. I'll look at that at some point, but I'm not worried about it too much. At least they don't crash the editor anymore.


3

There are cornercases where the preview is different from your actual post. What you see is caused by the intra-word emphasis feature The preview is, for obvious reasons, rendered client-side. When you post the markdown is parsed and transformed to HTML and stored in the Posts table. This guarantees it can be served to viewers without having to be parsed/...


Only top voted, non community-wiki answers of a minimum length are eligible