Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
Bug report: http://mathoverflow.net/questions/5897/why-the-rank-of-a-locally-free-sheaves-is-well-defined/5927#5927
ah, Greg's trick fixes this.
I don't like Greg's trick. It wraps the mathematics in a code block when it isn't a code block and relies on the jsMath to ignore the code block. I suspect that this could look horrible in the wrong browser. Also, it's like using a screwdriver to hammer in a nail: it's not the proper use of this syntax so this won't be taken into account if there's a proposal to change the behaviour.
Wrapping the mathematics in p-tags is cleaner because it turns Markdown off inside the block and this is the intended behaviour of putting a block in a p-tag. Admittedly, it means that you can't use Markdown syntax elsewhere in that paragraph, but that's no great hardship.
That particular entry still wasn't displaying correctly so I put in p-tags to fix it and it now looks right to me.
Regarding the double-star in the preview, I get the problem even when it's in the middle of a line. That is, saying writing "So by **Banach-Steinhaus** we get ..." then the preview shows "So by *Banach-Steinhaus* we get ..." (actually, I'm not sure if the stars are within the italic or outside).
Not so much a bug with jsMath, just one to add to that "jsMath Ain't LaTeX" list: \cdots doesn't work. It appears to produce a list of less-than-or-equal-to signs. I've seen this a couple of times (most recently by David Speyer, no less) so figure it ought to be noted somewhere.
Regarding \cdots, I can't reproduce the error. It works as expected.
On the one hand, I agree that Greg's trick is crufty, but it's actually a really nice way to tell Markdown to leave the underscores alone, and if you're using an old browser (or browsing with javascript disabled), I don't feel like the <code> tags are disturbing.
I've implemented danlec's live preview, which should be awesome ... no more "Preview Math" button necessary. I think this makes it all the more desirable to make the preview match the final post as closely as possible. I'll try to work on it later this week. If anybody is interested in helping debug/code (Ilya?), let me know if you do anything so that we don't cover the same ground twice.
Apparently, the live preview doesn't work properly on IE7. Does anybody know why this happens and how to fix it?
Maybe the cdots is a font issue. I'll see if I can experiment a bit. I thought I'd seen it at work (where I have the STIX fonts installed) but maybe it was just at home (where I do seem to have a few missing symbols). Next time I see it, I'll take a screenshot.
Is there an equivalent of \operatorname in jsMath? I am guessing the answer is “no” or “not in an obvious way”, since Andrew didn't get his supp right, and knowing him, I think he would if he could.
*looks at floor in shame*
I suspect that that was a hangover from using itex over at the n-lab. If something isn't an operator, just putting 'hello' defaults to an operator (which is why it's terribly important there to write 'f g' and not 'fg'). I'm used to these web LaTeX clones being a subset of LaTeX so I try to tread carefully and not assume that commands work, especially if they're not "mainstream" ones. It would be useful to have a quick summary of the differences and what does work easily findable.
@hanche: \operatorname seems to work just fine for me.
If anybody is interested in helping debug/code (Ilya?)
The regexps in wmd.js scare me! If nobody volunteers to fight them, I'll eventually get to that, but it may not be exactly soon.
@Kevin:
HTML tags are allowed in the Markdown.
@Kevin and Ilya, yes but only a very limited list and then you have to get the attributes exactly right. There's a question on meta.S[OE] about this somewhere.
Only a limited set of html tags are allowed to prevent cross-site scripting and other exploits. Here's a list of all allowed html tags.
Note also Anton's comment on that list; this issue surprised me.
jsMath appears not to have the $\mod$ command.
The link in amatthew's post is broken. The correct link does not have a period at the end.
Regarding mathfrak, Anton, can you try adding the following?
jsMath.Font.Load("eufm10");
jsMath.Macro('mathfrak','\\eufm #1 ',1);
@Scott: I did this, which seems to work (some of the details of why things have to be in this order are still a mystery to me
jsMath.Parser = {prototype: {macros: {
mathfrak: ['Macro','{\\eufm #1}',1],
operatorname: ['Macro','\\mathop{\\rm #1}',1],
implies: ['Macro','\\Rightarrow'],
Diamond: ['Macro','\\diamondsuit'],
mod: ['Macro', '\\mathop{\\rm mod}']
}}};
...various other jsMath stuff...
jsMath.Font.Load("eufm10");
upshot: \mathfrak, \operatorname, \implies, \Diamond, and \mod should now work as expected.
Regarding regexps in the modified wmd.js:
I don't have any experience of the peculiarities of javascripts interpretation of regexps, but I have messed around with them in perl and php. I've tried a few things on the test site, and played with a javascript regexp tester.
First, some general advice:
The classes for before and afters are best defined by exclusion rather than inclusion.
I think that trying to do both stars and underscores in the same regexp is doomed. The problem is that _**a**
produces _**a** but ***a**
produces *a. So trying a simple exclusion match is problematic.
It seems that the don't-convert-mid-word-stuff applies to the start of the markup, not the end. So Un*believable*
doesn't get converted but *Un*believable
does.
However, the stuff afterwards does matter when it is a star or underscore. Thus *a**
is not converted, but *a*_
is, whilst **a*
is converted (to italics), whilst _*a*
is not.
Learn about the 'm' and 's' flags: one of the problems with the current regexp is that it doesn't match at starts or ends of lines. By using the 'm' and 's' flags correctly, one can overcome this without too much difficulty.
The following worked on my test suite for double stars:
(?:^|[^A-Za-z_\\])\*\*([^\*_][^\*]*?)\*\*
I haven't yet figured out the single stars version (the tester seems to be going haywire).
Is someone looking at Fedja's comments here, to try to figure out what went wrong?
I started writing a Markdown torture test, which we can use to test proposed modifications to the way wmd.js handles italics and bold. Ideally, we should change wmd.js to produce exactly the same (crazy!) output.
This modification of Andrew's regex works pretty well for bold:
(?:^|[^A-Za-z_\\])(\*\*|__).*?(\*\*|__)($|[^A-Za-z\\])
but I can't quite get something that matches the following line properly:
**internal _'s and *'s (even __'s and **s) don't** break bold (note that "**s) don't**" wasn't converted separately ...)
which should produce
internal _'s and *'s (even __'s and **s) don't break bold (note that "s) don't" wasn't converted separately ...)
I'll see what I can do about italics later. If you're going to experiment with it, remember that wmd.js does the bold conversions first, so you should change all matching double stars/underscores to <strong> and </strong> before applying your regex.
I've changed the italics/bold conversion function on MO and faketestsite to do the following replacements in the following order:
text = text.replace(/(^|[^A-Za-z_\\])(\*\*|__)(.*?[^ \\])(\*\*|__)($|[^A-Za-z\\])/g,
"$1<strong>$3</strong>$5");
text = text.replace(/(^|[^A-Za-z_\*\\])(\*|_)([^ \*_][^\*_]*?[^\*_ \\]|[^\*_ \\])(\*|_)($|[^A-Za-z\\])/g,
"$1<em>$3</em>$5");
text = text.replace(/(^|[^A-Za-z_\*\\])\*\*([^ _][^<]*?[^_ \\]|[^_ \\])\*\*/g,
"$1<strong>$2</strong>");
text = text.replace(/(^|[^A-Za-z_\*\\])\*([^ _][^_\*<]*?[^_ \\]|[^_ \\])\*/g,
"$1<em>$2</em>");
This seems to fix all bugs I've come across. I challenge somebody to find a discrepancy between the preview and the final output (having to do with italics and bold; I know there are some other issues).
I'd rather a wiki-like page for recording hints and tips for jsMath. Even if this thread were reachable, it's hard to slurp through the whole morass looking to see if your particular issue has been dealt with already.
I've added a link to this thread from the "How to write math" sidebars and made the discussion sticky.
The math in my answer here keeps spilling over the right margin. Actually, I just installed the jsmath "special fonts" earlier today. I had very minimal right-margin-spillage problems prior to this; now I seem to be having many. So I guess it's probably because of the fonts. I'm using Safari 4 on a Mac, if that matters.
Btw, the preview/final output discrepancy bug has been completely fixed on SO. Hopefully those changes will be merged into SE soon.
Somebody reported the following problem with jsMath to me. Browsing this question with Safari on a Macbook, instead of getting the correct output (left), he gets the output on the right:
I've asked him to check if he also has the same problem with MathJax's preview page.
I'm pretty sure he doesn't have the fonts installed, so it's a problem with the image fonts. It must be related to the problem Andrew reported with \cdots earlier in this thread.
He's also just confirmed that everything looks good with the MathJax preview page.
Works fine for me, Safari 4.0.4 on an MacBook Air, no fonts installed.
Out of curiosity, why is this no longer sticky?
I unstickied it more or less on a whim last night. The reasoning was that it's been a long time since a bug was actually reported here rather than reported elsewhere and copied here by an old hand, and that this thread is likely not very useful to anybody who didn't read it as it was happening. But I guess that was as true (or false) three weeks ago when it was requested that this thread be sticky, so I'll re-sticky it. Sorry about the confusion.
@Sam: Try deleting the jsMath cookie from mathoverflow.net. That resets all the jsMath settings to default for me.
Does escaping the asterisk with a slash in front work?