Not signed in (Sign In)

Not signed in

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

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

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

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • 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.
    • CommentAuthoradeelkh
    • 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.
    • CommentAuthoradeelkh
    • 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

    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?