Code is indented incorrectly

Question

I recently pasted the following code:

    my @cards = qw(BB BR RR);

    my $n_trials = shift || 100;
    for (1 .. $n_trials) {
      my $card = $cards[ int(rand 3) ];
      my @faces = split //, $card;
      my $face_choice = int(rand 2);

      my ($face, $other_face) = @faces[$face_choice, 1-$face_choice];

      if ($face eq "R") {
        # this trial is spoiled; do it over
        redo;
      } else {
        $count{$other_face} += 1;
      }
    }

    print "In $n_trials trials:\n";
    for my $other_face (keys %count) {
      print "  The other face was '$other_face' in $count{$other_face} trials\n";
    }

The Markdown engine displays the code incorrectly. For example, the for in the fourth line is indented by eight spaces, the same as the my on the third line. But it is displayed as if it were indented 12 spaces.

Similarly, the three following lines that begin with my should all be aligned the same, but the third (my $face_choice) is indented four spaces too far.

There are other errors; you can view the source of this note to see how it should be indented.

The code does not contain any tabs or trailing spaces.

Here is a screenshot that shows the incorrect rendering, in case it works properly on your browser.

Answer 1

It appears to be a conflict between the code formatting and MathJax. For comparison, here is your code, but with all of the dollar signs replaced by S's:

    my @cards = qw(BB BR RR);

    my Sn_trials = shift || 100;
    for (1 .. Sn_trials) {
      my Scard = Scards[ int(rand 3) ];
      my @faces = split //, Scard;
      my Sface_choice = int(rand 2);

      my (Sface, Sother_face) = @faces[Sface_choice, 1-Sface_choice];

      if (Sface eq "R") {
        # this trial is spoiled; do it over
        redo;
      } else {
        Scount{Sother_face} += 1;
      }
    }

    print "In Sn_trials trials:\n";
    for my Sother_face (keys %count) {
      print "  The other face was 'Sother_face' in Scount{Sother_face} trials\n";
    }

Now the displayed version matches the actual number of spaces used. I don't have any idea about the specifics of what's going wrong, or how to fix it, but I'm sure that Davide Cervone will be able to sort it out.

---

I remembered that the <pre> HTML tag acts like the four spaces do in markdown, and it appears that formatting code in this way avoids the issue (somehow):

        my @cards = qw(BB BR RR);

        my $n_trials = shift || 100;
    for (1 .. $n_trials) {
          my $card = $cards[ int(rand 3) ];
          my @faces = split //, $card;
      my $face_choice = int(rand 2);

          my ($face, $other_face) = @faces[$face_choice, 1-$face_choice];

Answer 2

The handling of MathJax in Markdown is rather awkward, since TeX and Markdown have different interpretations for things like underscores. You need to keep Mardown from processing those character inside of mathematics, and the way it works on StackExchange is that the mathematics is removed before Markdown runs, and then reinserted after the Markdown processing is complete. That means that anything that looks like mathematics is taken out of the page during Markdown processing, and that includes anything between dollar signs.

This approach works most of the time, but if the dollar signs are in a code block (where they really don't end up delimiting mathematics), that means that the material between the dollars hasn't been processed by Markdown. In particular, there is no normalization of the leading spaces, and that is what you are seeing here. Markdown removes the four initial spaces that indicate a code block, but between dollars they are being retained, thus your spacing issue. When you use the <pre> directly, all the spaces are retained, as Markdown does not modify the contents of the <pre> (notice that your <pre> example has four more spaces than the plain indented example), and so the spaces within the material removed as mathematics and replaced later no longer is a problem since the code material is also indented to the same amount.

The real solution is to incorporate knowledge of the math delimiters into Markdown itself, so that Markdown knows not to perform its usual substitutions within the math. The SE folks (rightly) don't want to modify the Markdown processor directly, which is what lead to the partial solution that currently exists.

The next best thing would be to make the preprocessor that removes the math be more aware of the surrounding Markdown so that it can recognize situations like the one you have here and not remove the "math" in that case (since it is not actually going to be processed as math in the end) so that it gets properly handled by Markdown. I worked on that at one point, but it is more delicate than you might think, and practically ends up requiring writing a Markdown processor in order to get it right.