Thinking a bit about this, I don't think the choice of opening/closing strings should be made based on who uses what, simply because... well, at some point anyone might choose any particular string for some reason or another, and then what. On the other hand it's damn near impossible to escape in-bandism, so I think this should rather be a configurable knob, more precisely a PHP constant (or two of them?) that's set to whatever the user desires.

For the record, The Tar Pit uses the footnote functionality provided by the Markdown plugin instead of footnotes.php (which is also why the lack of footnote tooltips), so this wouldn't affect me either way. Moreover, IMHO it's on me to port the functionality from one place to the other if I need it, so I guess this solves that.

The current implementation would result in x]]y[[z formatted inside a codeblock (I just tested to confirm this). If you wanted it to be just z inside the codeblock you could use [[ to escape the opening tag.

Have you ever run into this with (()) on Trilema, for something you wanted to display normally and not as a footnote?

For example, before I prevented the footnotes processing from being applied to codeblocks the footnotes matcher would inevitably turn up a few false positives in the code snippet.

In any case I do think [1[ ... /]] is the better option, but even so, if for some reason you had [1[x]]y[1[z/]] and you only wanted z in the codeblock you'd be stuck escaping the opening tag again.

I'm not trying to argue strongly for any one tag, just saying that I'm finding it very difficult to come up with something that will work as intended 100% of the time.

FWIW markdown uses ``` code goes here ``` for codeblocks. But I understand spyked uses markdown for his blog so it would at least be a non-starter there.

I think this view is at best naive. What's the result of [[x]]y[[z/]] iyo ? x]]y[[z or just z ?

To clarify my thinking around changing the (trivially adjustable) default footnote identifier from decimal to lowercase-roman: every republican blog (including this one until making this update) used decimal, except Trilema (and I now notice Fixpoint uses roman numerals as well). My assumption was that blogs were all using decimal because no one bothered to change the default (perhaps I'm wrong). But Trilema (and Fixpoint) using something other than the default meant it must have been intentional. So I figured rather than make MP adjust it on his blog, just change the default that most probably didn't think twice about in the first place. And I kinda like the roman numerals now.

That being said, it really makes no difference to me what that constant is set to, as it has no effect on the functioning of the code and can be easily changed by whoever is using it. It sounds like people prefer I leave it as it was, set to decimal by default?

> Would [1[ blabla ]] syntax be terrible ? Where 1 is an index value of supported langs ?

This certainly seems fine to me. Something for a future patch to build on imo.

> There'd be a number of extant Trilema articles that'd be problematic atm (1, 2, plus a dozen or so log days, such as say randomly 3). The problem's not merely bash, but also plain regexp, xml data formats, etc.

> You know, the fact you added something so the ]] isn't matched anymore doesn't mean [[ isn't still.

The way the regex matches though is by the open and close delimiters. So there can be as many [[ in the code as you want and it won't trip up the matcher. That's why adding that little slash in /]] was so effective at making this safe for bash, regex, xml, etc. Those example Trilema logs you linked to should work fine as well.

On the other hand, though I quite like [[ /]] for its brevity and ability to work with just about any code example I could find, I am not married to it and it's just a string so I certainly don't mind changing it to something else.

EDIT: To expand on that last bit, MP's suggestion of [1[ ]] is equally concise, and 1 could represent vpatch diffs since it's the first implementation. I think I might like this more than [[ /]] now.

Imo decimals work a lot better with some modernist themes, perhaps foremost spyked's.

> Just a thought, I'd personally like to see custom syntax highlighting at some point for non-vpatch snippets.

This is actually a very strong point. Getting auto-highlights for a few of the most used langs would be a pretty massive win in all directions, including removing the very clunky documentation tools currently in use. I dunno I want doxygen or whatever anymore, if there's native highlighting, adnotation, trackbacks, holy god perfect manual software.

Would [1[ blabla ]] syntax be terrible ? Where 1 is an index value of supported langs ?

> Bash definitely uses double-brackets as builtin operators.

There'd be a number of extant Trilema articles that'd be problematic atm (1, 2, plus a dozen or so log days, such as say randomly 3). The problem's not merely bash, but also plain regexp, xml data formats, etc.

> Yup, exactly it.

You know, the fact you added something so the ]] isn't matched anymore doesn't mean [[ isn't still.

D'oh, I forgot to call this out. I meant leave a not about it in the article. I used to have decimal identifiers on this blog as well, I changed to lower-case roman numerals because that is what's on Trilema.

> Oh hm, you *did* include the slash-quoting for MP_WP_CODEBLOCK_CLOSE but left it out for the other three - why the special case?

The other three, `[[`, `((`, and `))`, don't contain a slash. The slash was added to the codeblock close because `]]` by itself would be matched in bash scripts.

> Merciful Zeus, horizontal scrolling?

The horizontal scrolling is something I didn't think much of because I was using a trackpad (scrolls left/right as easily as up/down without looking for the scrollbar). You can also hold shift while scrolling with a mouse scroll wheel to move horizontally.

Applying `white-space:pre-wrap` and max-width on the code worked but I also think the code itself should be formatted to not have such long lines in the first place. I'm not entirely sure the plugin's default should be to wrap your lines of code.

What I've seen on a number of republican blogs is exactly this, a fixed width code box with horizontal scrolling. Is this perfect? Probably not but it avoids text lines breaking out of the layout and causing the entire page to horizontally scroll, or machine-wrapping the lines, which can be just as unpleasant to read. That being said, the CSS is customizable and a user can choose to style it however they like.

> Just a thought, I'd personally like to see custom syntax highlighting at some point for non-vpatch snippets. This would need a way to specify language though so perhaps this bracket tag isn't the right thing to built it on.

I agree although I don't have any good suggestions off the top of my head for what the delimiters would be. I've seen things like [[python]] ... [[/python]] before so perhaps something like that. MP suggested hijacking html's <code> but I didn't want to do that here because I rely on <code> for inline styling of variables and such.

> Bash definitely uses double-brackets as builtin operators. Is that why you used the / for the closing?

Yup, exactly it.

> Though I get the desire to minimize friction.

Yes and the fact that literally the only awkward case I came across was the one in this article with code containing the code delimiters themselves. This hardly seems like an edge case worthy of requiring sed pre-processing for anyone wanting to post html-containing snippets.

2. Since double-paren footnotes are officially non-optional now, I'd rather it go all the way and remove those WP_FOOTNOTES_OPEN variables that would falsely suggest otherwise, and the sharp edge of that broken preg_quote. Oh hm, you *did* include the slash-quoting for MP_WP_CODEBLOCK_CLOSE but left it out for the other three - why the special case? And why the special case of using a slash in the chosen delimiter too?

3. Merciful Zeus, horizontal scrolling? And since the scrollbar is buried pages down at the bottom, the only way I can read this at all is with the middle-click autoscroll bubble, and that's still rather a pain. See also and feel free to try the css I used there (inline white-space:pre-wrap).

4. Just a thought, I'd personally like to see custom syntax highlighting at some point for non-vpatch snippets. This would need a way to specify language though so perhaps this bracket tag isn't the right thing to built it on.

5. Bash definitely uses double-brackets as builtin operators. Is that why you used the / for the closing?

6. "but because the code snippet itself is sent through htmlspecialchars that wouldn't work either" - hm, might this be a case of "so don't do that"? Special chars already had to be escaped by the author, in code as elsewhere, so for the serious code-blogger, a sed script that deals with brackets, parens, less-thans and ampersands in one shot seems no worse a workflow than before. Though I get the desire to minimize friction.