Why are <= 3 spaces allowed on the line before code fences?

Spec
1

The spec for Fenced Code Blocks says:

A fenced code block begins with a code fence, indented no more than three spaces.

What’s the use case for 1-3 spaces before the fence? I understand that four would indicate that the fence is itself actually part of an indented code block, and I get why fences can be longer than three ticks, but I can’t find a good reason to have spaces before the fence.

I mean, I get that you can slightly indent the code block using leading spaces that’ll be removed on render, but boy, that seems awkward, and I don’t know that I’ve ever wished I could do that. When would that be practical? Perhaps folks that enjoy two-space tabs and prefer fences?

If there’s no great “cultural” use case, don’t you have an Occam’s Parsing Razor argument (essentially, “to break a tie, don’t backtrack when parsing”) not to allow 1-3 spaces?

(Which is just to say I imagine there’s a cultural argument in here somewhere that I’m missing. ;^D)

No big deal either way; just curious about the use cases. Thanks!

Btw…

A backtick string is a string of one or more backtick characters (`) that is neither preceded nor followed by a backtick.

Boy, that’s ungainly.

Maybe better?

A backtick string is a string of one or more consecutive backtick characters (`) which is followed and/or preceded by non-backtick characters."

2

Guessing (and to be clear, this is truly a guess) that this has to do with making code blocks and block quotes behave nicely together.

While you might not indent

```
example
```

In a blockquote you might want to organize your text as:

>   lorem ipsum
> 
>   ```
>   example
>   ```

Using a tab width of alignment.

1 Like
3

Ah, gotcha. Take code, indent a block, then edit a column from spaces to >. That’s interesting. Or at least put some space between your block markers and the code start in the unrendered text. Feels edgy, but if that’s a common usage, that’s smart.

Though now you’ve got me wondering if I should change my email client’s compose window to force fenced blocks around indented code blocks on send.

And boy, when you babelmark2 the below, what a mess, huh?

>   ```
>   /*jslint unparam:true, white:true */
>   var http = require('http');
>   var unirest = require('unirest');
>   var fs = require("fs");
>   //var qs = require('querystring');
>   ```
4

Shouldn’t the blockquote consume that indent?

5

Yep, the rendered blockquote would eat the indent. I think it’s just giving a little space in the pre-rendered Markdown to make the text more visually appealing. That’s what I understood from @zzzzBov anyhow. ;^)

If you use something like VIm’s visual blockwise editing feature, it’d be easy to indent and then change to a blockquoted piece of code that still looks nice. /shrug

It’s edgy, but I could see that being a useful workflow.

6

Per spec

A block quote marker consists of 0-3 spaces of initial indent, plus (a) the character > together with a following space, or (b) a single character > not followed by a space.

Sounds like block quote consumes 1 space after the >, fenced code block consumes the other 2.