Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
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.)
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.
but in my opinion, it is a change in the wrong direction
I second that.
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.
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?)
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.
That’s really useful, thanks Andrew. When I get a moment I’ll try to go sort through the matches.
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.
Another thread bulleted lists in nLab was started on Aug 12 2015 about this problem, but further discussion should probably continue in this thread.
There I said:
I, and I’ve noticed other people, tend to edit in a blank line after viewing a page with a broken list, though in one case I fixed somebody’s fix who didn’t know that only a blank line was needed.
If a page has unfixed lists does that mean that nobody knowledgeable has read it since last August?
1 to 9 of 9