Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 157 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

I can't see quite what causes this, but there's a funky markdown bug apparent in my answer here:

The two Lisp-y code snippets should be formatted just the same, but the second one is messed up. I went over it a couple of times checking the spacing and couldn't make it right. The same thing seems to happen if I post the text here, so I've added it below.

You have to define them both as separate templates. Then you can store either fact-id or some other identifier for the "sub-fact" in the main fact, then join the main fact pattern with a "sub-fact" pattern using that value:

(defrule blue-eyed-person
    (person (name ?name) (eyes ?eyes))
    ?eyes <- (eyes (color blue))
    (printout t ?name " has blue eyes." crlf))

Or alternatively

(defrule blue-eyed-person
    (person (name ?name) (eyes ?eyes))

        (eyes (id ?eyes) (color blue)) => (printout t ?name " has blue eyes." crlf))

share|improve this question
See my answer here in case this happens again. – balpha Apr 26 '12 at 7:40
up vote 4 down vote accepted

How did you generate those two code snippets? They're not exactly the same as one another, so it couldn't have been by copying and pasting.

There are some funky Unicode space characters that are masquerading as plain old boring spaces before the line of code in the second block that begins ?eyes. Markdown isn't recognizing those as spaces, so the line is not being properly indented.

Replacing those characters with regular spaces (or copying and pasting the whitespace from the first code block) causes Markdown to format the second code block correctly.

You're not the first person with this problem. It seems others have had trouble with funky Unicode characters getting inserted, as opposed to regular old spaces. No one seems to have come up with a good explanation for why, and the team seems to have decided not to change the behavior.

share|improve this answer
Son of a gun, I tried editing again in my post above, and this time I was able to fix it (I left the broken version up above, or my question makes no sense!) I created the second one originally by copy-pasting and editing the first, so I wonder if the copy-paste is what added the nonbreaking spaces. – Ernest Friedman-Hill Apr 25 '12 at 22:13
Then what browser/OS/etc did you use, @Ernest? And did you copy from the editor textarea, or from the preview, or somewhere else? – Arjan Apr 25 '12 at 22:27
Chrome, MacOSX, editor textarea. – Ernest Friedman-Hill Apr 25 '12 at 22:39

I can't be absolutely sure, but it seems you had something like non-breaking spaces in that snippet. I deleted the spaces in front of the offending line and typed eight normal spaces, and it's formatted okay now.

share|improve this answer

You must log in to answer this question.

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