Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Fenced code in footnotes #11

Closed
waylan opened this Issue · 4 comments

2 participants

@waylan

Unlike lists (see issue #10) this works fine (showing footnote def only):

[^1]: ~~~
code
~~~~

So does this:

[^1]: 
    ~~~
    code
    ~~~

And this appears to work properly (but may not be if you consider the next example):

[^1]: ~~~
    code
    ~~~~

This does not work for sure (all indentation is lost):

[^1]: ~~~
code
    indented code
~~~

Which makes me wonder if perhaps the first example should not work (like lists currently work).

This does work:

[^1]: 
    ~~~
    code
        indented code
    ~~~

And weirdly this works two (notice lack of indentation to indicate we are in a footnote def):

[^1]: 
~~~
code
    indented code
~~~

But maybe that last one is right because we have no blank line??? Adding a black line takes it out of the footnote and leaves it in the main doc body - as it should. That said, with 2 defs this is hard to read even though it works fine:

[^1]: 
~~~
code
    indented code
~~~
[^2]:
~~~
more code
~~~

Requiring indentation makes it much more readable.

@michelf
Owner

I'm not sure what point you're trying to make. Are you saying you expected the fenced code blocks to not be part of the footnote because they're not indented?

As for your forth example, I wouldn't expect it to work because the footnote doesn't asks for its content to be indented. Sure, you're not required to indent the content in all situations (you're allowed to be lazy like elsewhere), but if the opening fence is indented so should the content.

@waylan

I guess my point is that the results seem to be inconsistent and in some cases surprising. I was expecting the same behavior at with lists and I'm getting something different.

Regarding the forth example, I understand how that would work if it was a (lazy) paragraph, but this is a code block - where whitespace matters. Once we find an unindented line, then any indent on additional lines must be preserved. At least that is the expectation I had as first, and I understand the markdown syntax better than the average user (having implemented the same in Python-Markdown).

At first I didn't understand what you meant by your last statement ("if the opening fence is indented so should the content"), then I tried this:

[^1]:     ~~~
    bar
        baz
    ~~~

That really surprised me. I expected that to be a (indented style) code block of a fenced code block.

Perhaps the way Python-Markdown parses footnotes is clouding my view though. Basically, we removed the reference [^1]: and any non-lazy indent and then pass the whole footnote body through the parser as if it was a separate document. On further reflection, Python-Markdown would probably give different, albeit just as surprising results in some of these cases.

The point of all this is that I was looking at how your implementation works so mine can emulate it. If the current behavior was intentional, that's fine, but without it documented I assumed the surprises to be bugs.

@michelf
Owner

Oh, I see now! You find it surprising from an implementer perspective. (I should have though of that.) Well, I was't sure why it did that before I took a look at the code. Turns out that fenced code blocks are handled before stripping footnotes. So this:

[^1]:
~~~
   abc
~~~

gets converted by this:

[^1]:
<<here a hash code that'll be swapped later for the code block>>

And then the hash code and later the code block end up in the footnote. I can't remember whether this was intended or just a fortunate side effect (probably the later), but it's the right thing to do. The basic idea behind a fenced code block is that, regardless of how parsing works, the content of the code block should be outdented by as much as the opening fence is indented. How much the opening fence is indented is a tricky question when the marker is on the same line, but I think it's fair to count the marker as an indent.

As for the indented code block containing a fenced code block, it should be written like this:

[^1]:     ~~~
        bar
            baz
        ~~~

But it doesn't work. I'm wondering if I should treat it as a bug or not. But you can still do it like this:

[^1]:
        ~~~
        bar
            baz
        ~~~

And it even looks better.

@michelf
Owner

I guess this is not really an issue anymore, so I'll close it.

@michelf michelf closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.