Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
One problem would be backwards compatibility: we'd need to come up with an algorithmic way to edit all the old posts, and then presumably cooperation from Fog Creek to actually apply those edits to the database without having to actually edit through the web interface.
Once the decision to use markdown has been made, I think it's better to stick with it. Having a gazillion incompatible dialects of markdown would be a pain in the posterior. That said, it would be nice if it were possible to tell markdown about the magical aspects of dollar signs, so it would refrain from doing its thing within TeX code. (You might object that markdown with magical dollar signs is just another markdown dialect, but this difference is at least much easier to explain to mathematicians.)
Markdown and whatever can be integrated properly so that each knows about the other. The thing is that they need to act together, not one after the other. The n(Lab,Forum) system seems to work quite well with this, I certainly don't know of any cases of the two syntaxes getting confused. Actually, it is also possible to do them one after the other, but a little bit of trickery is needed first (the nForum uses both systems, depending on which formatter you use).
If n* can make markdown and latex work together, then why can't we?
For the simple reason that over at the nStuff, I have complete control over everything that is installed. (Fortunately, for the nLab, I don't have to since Jacques Distler already writes darn good software, but the nForum is extensively extended; fortunately, it is designed with such extensions in mind.) But here at MO, Anton only has limited control over what's there.
By the way, Markdown modifies the list numbers so that you don't have to remember to adjust them if you go back and insert something half-way through. So if I write a TODO list:
1. Define "wibble"
2. Prove that every "wibble" is a "wobble"
3. Deduce Riemann Hypothesis
and then decide that I ought to add in a step between (2) and (3) then I can just write
1. Define "wibble"
2. Prove that every "wibble" is a "wobble"
2. Explain relevance of "wobbles" to the axiom of choice
3. Deduce Riemann Hypothesis
and not have to rejig my numbering scheme.
Markdown does it's best to "play nice". One useful feature of it is that it respects "keep out" signs. If you want to turn Markdown off in a paragraph (or larger) then you can, simply by enclosing the whole section in <p> tags. It's hard to illustrate here, but just try experimenting and you'll see.
Over at the nForum, we're enlightened and allow you to put in any XHTML code that you want (I run it through a sanitiser to strip out nasty stuff). Here, XHTML code gets automatically stripped so I can't demonstrate it, whilst the SE/SO software has a very limited whitelist of allowed code. So I can't demonstrate all the possibilities of Markdown (or Markdown+maths) here or at MO, but at the nForum we have some Scrap Paper where you're welcome to doodle.
In particular, on MO and the nStuff, you can type a list using proper XHTML code (<ul>s and all that), but only at the nStuff could you modify the style (via inline CSS) of those lists so that your own numbering scheme was preserved.
(And in posting that here, I've just demonstrated that the Markdown implementation is not quite right: I wrote "<p>" in backticks in the hope that it would display as "<p>", but because of the way the implementation is done here, it got translated into "<p>".)
@Peter: I actually use both * (or _) and **
Which is why it's better for individuals to know how to turn it off than for the admin to enact it themselves.
Still, I think that your point about better integration between markdown and (whatever-produces-maths) is valid, just not possible with the current set-up.
A nice solution might be to do something like what happens here: a checkbox at the bottom of the "post" form so you can indicate that your text should be formatted with or without markdown. It would require help at the server end, but such things aren't impossible in the long term. This also avoids the backwards compatibility issue, and the software could remember your preference.
I actually find markdown emphasis useful, and so do other people: a cursory look at a recent database dump shows that 19763 lines in posts used *, and only 4202 of those were between dollar signs (and that's an overestimate because I used a dumb regular expression which can't tell if you're within math or simply between math).
Since the only problem is when * or _ appear in math, the right solution is really to have the server ignore special markdown characters within math. As Scott said, help at the server end is not impossible in the long term, but I don't know how long it would take to push something like this through. It's even possible to modify the editor so that it automatically inserts backticks around math that looks like it might cause trouble, but I'm not very excited about trying to implement and maintain that.
I do use markdown regularly now that I learned how to use it, but I can't think of a reasonable use of markdown inside math. Couldn't the editor simply backtick all math?
Markdown shouldn't look inside mathematics, but the right solution is to tell Markdown about dollars, not about circumventing the code block methods. Markdown does look inside code blocks so using backticks is not guaranteed to be clean. The right solution is for the Markdown and mathematics converters to be integrated so that they both know about the other. Unfortunately, that's only possible if one has access to both.
@Andrew: I think we have a case of "perfect is the enemy of best" here.
@Scott: I prefer to think of it as "'it looks alright to me' is the enemy of the best".
If you take a look at the nforum now, you'll see that it is possible to have ones MathML and see it, too.
@Andrew,
I think we've decided that the optimal future track (given the constraints of our access to the underlying software) is:
1) switch from jsmath to mathjax, when mathjax is ready. The server will provide math surrounded in $ ... $, in the latex input form. Mathjax will convert this to either MathML, for the browser to interpret, or html+css for older browsers, via javascript. Users without javascript will just see latex source.
2) hope that eventually we have access to the markdown engine on the server, and have it not look inside $ ... $.
3) hope that it eventually becomes possible to have the server translate latex input to mathml, and serve mathml directly, but only to users who have set a preference requesting it (or have a user-agent string that reliably predicts mathml support).
@Scott: I thought that instead of (3), the plan was
3') Hope that it eventually becomes possible to have the server translate latex input to mathml, and serve mathml directly to everybody. MathJax will "convert" this to MathML (i.e. leave it alone), or html+css for older browsers, via javascript.
The downside is that users without a MathML-capable browser and no javascript will see MathML instead of LaTeX. We could user a user-agent string and/or a preference as additional lines of defense against this problem.
I'm really pleased to read all that.
That the word (abbreviation?) "MathML" occurs so often is progress for me. Now I just have to convince you to ditch the word "javascript".
There really is no need to do any of this with javascript. Once you get your hands on the markdown code (and I consider this discussion relatively academic until that happy day), then you can simply choose to convert the latex-lite into MathML or other format according to what the end-user can see. That way, you server MathML to those who can see it, and Something Else to those that can't. You could even send the bare source if someone really wanted to see that. (Though anyone claiming that they can "read" LaTeX source more easily than anything else has never tried looking at the source of one of my papers. What they really mean is "latex-lite" but then that's what we're talking about here as well.)
All that is possible and is possible server-side. And it should be done server side, not client side. There are lots of reasons why so, but perhaps the biggest is speed. If it's done server side, the conversion can be cached and then everything gets so much faster and slicker. You do the conversion once per post per format, and that's that. All done.
But let me reiterate this point: all of this is completely possible once you get access to Markdown. Indeed, it's what we now do on the nForum: MathML to those that can, SVG/PNG to those that can't. Maximum accessibility, maximum customisability, maximum useability. Oh, and zero sugar, of course.
1 to 19 of 19