# Start a new discussion

## Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

## Site Tag Cloud

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

• CommentRowNumber1.
• CommentAuthorTobyBartels
• CommentTimeAug 11th 2014

Some recent update to the Markdown used on the Lab has broken many lists (both ordered and unordered). It used to be that you could create a list with

Text
* Item A
* Item B


but now this fails; instead, there must be a blank line between the list and the preceding text, or it won't parse as a list. (This was long the case on the Forum, and it was long the case for text after the list, so this is at least a change in the direction of consistency; but in my opinion, it is a change in the wrong direction.)

• CommentRowNumber2.
• CommentAuthorTobyBartels
• CommentTimeAug 11th 2014

I usually fix entries when I find them, but I'll leave fan theorem alone so you can see how it works; under Use in analysis.

• CommentRowNumber3.
• CommentAuthorzskoda
• CommentTimeAug 11th 2014

but in my opinion, it is a change in the wrong direction

I second that.

• CommentRowNumber4.
• CommentTimeAug 28th 2014
• (edited Aug 28th 2014)

Looking at the recent changes to the Markdown parsing library, it seems that it was changed to require an empty line before a list. For example,

This won't work:
* item 1
* [...]

But this will:

* item 1
* [...]


I have edited the page linked in #2 to work with this new syntax. I am not sure how many lists this has broken throughout the nLab. If there are a significant number, we can just use a forked version of the Markdown parser that behaves as we require it to. Personally I haven’t seen any broken lists other than the one Toby linked to, but if someones produces a list of several examples then I’m willing to fork the parser.

• CommentRowNumber5.
• CommentAuthorDavidRoberts
• CommentTimeAug 28th 2014

I fixed one earlier today, and saw another one before that that I didn’t get to fixing (can’t remember where!) Searching for * in plain text might work, I can’t guess why these would otherwise be used (maybe C*-algebra?)

• CommentRowNumber6.
• CommentAuthorAndrew Stacey
• CommentTimeAug 28th 2014

Using a multi-line grep on the bzr repository should pick these up. Experimenting with fan theorem, I think that the following expression should pick them up:

pcregrep -M '^ *[^\*\s][^\r\n]+ *\r\n *\*'


I’m on a Mac so my line endings are \r\n. Other systems may differ.

The regexp is: match the beginning of the line, then arbitrary spaces, then a non-asterisk and non-space character, then any non-line-ending characters, then maybe spaces (actually, could skip this), then a newline, then maybe spaces, and finally an asterisk.

Reading the pcresyntax man page, and experimenting a bit with what’s allowed before a list, I can condense it a little to:

pcregrep -M '^ *\w[^\r\n]+\R *\* 


but this still produces a lot of false positives, mainly where we’re in a list and the previous item goes over two lines so the naive search thinks the previous line is part of normal text instead of a list item.

With the above regexp, I got 240 pages.

Here’s the full “script” that I ran on my command line:

for f in *.meta; do
g=$(pcregrep -M '^ *\w[^\r\n]+\R *\* '$f:r)
if [[ $g != '' ]]; then grep -m 1 '^name:'$f
print \$g
fi
done


That prints the page name (might get it wrong if the page has been renamed) and the matching part. Then you can check if the match is genuine or warrants further investigation.

• CommentRowNumber7.
• CommentTimeAug 28th 2014

That’s really useful, thanks Andrew. When I get a moment I’ll try to go sort through the matches.

• CommentRowNumber8.
• CommentAuthorTobyBartels
• CommentTimeAug 28th 2014

I have seen several more. Sometimes I fix them, sometimes I don't.

Generally I find that Markdown requires far too many blank lines; this is just one instance. Blank lines have a semantic meaning (paragraph break) that is distinct from beginning or ending a list, etc. (HTML itself has this same problem, actually; far too many things are not allowed inside <p>` but should be, and XHTML makes it worse, to the point that I do not use XHTML when I write by hand.) I would like to make a global revision of Markdown to make it better in this respect. Obviously this is a huge project, especially maintaining such a fork afterwards. So I don't actually expect to do this.

• CommentRowNumber9.
• CommentAuthorRodMcGuire
• CommentTimeAug 13th 2015