Implemented #168

[Drezil]

This PR implements #168 as described in #168 (comment)

It should work for normal and nested blocks with both syntaxes described.

There are no tests yet, as i don't know how you want them implemented properly.

A stack test shows that it should not break other things:

All 968 tests passed (81.94s)

[Drezil]

(failed travis-check is due to timeout during compilation on their end for 2 of 4 vms)

[Drezil]

@jgm anything that is missing or i overlooked before this could be merged?

I am willing to invest some hours into this to get things released as soon and as smooth as possible ;)

Would the writer have to be updated as well to generate the corresponding md? so that read . write = id holds?

[mb21]

@Drezil It's great to have some working code to play around with and see how the syntax feels like to work with on real documents, however I guess this won't be merged until a syntax is decided for good... (uvtc's syntax was only a proposal and unfortunately the discussion seems to have stalled a bit)

[Drezil]

The discussion seems to have stalled for nearly 6 years now ;)

I argue that we need the feature with any syntax.

In my case i want to create slides via reveal-js and there you can do amazing things with divs + css-classes (like multi-column, triggers, ...). Put a good filter on top of it and you can customize the syntax as you like.

Problem at the Moment is that there was previously no way to create a Block-Element with Attributes (as Div is the only one), as this AST-Element never gets created in the markdown-parser.

Classify it as experimental or i can move it to an optional extension (like markdown+div) or so - i just think that we need (at least one) way to generate every element in the AST for filters & interop..

[mb21]

as this AST-Element never gets created in the markdown-parser.

you could always use the HTML div syntax which the markdown-reader parses as a native pandoc div.

btw, I agree that it would be great to decide on a definitive div syntax, but that's up to @jgm...

[tarleb]

i just think that we need (at least one) way to generate every element in the AST for filters & interop..

Using HTML syntax in markdown works for this:

<div id="foo" class="bar">
# Slide

Wassup?
</div>

This will wrap the elements in a div the AST as long as the markdown_in_html extension is enabled (which it is per default).

EDIT: mb21 was faster 😄

[tarleb]

I don't quite follow. For me, the above results in

[Div ("foo",["bar"],[])
 [Header 1 ("slide",[],[]) [Str "Slide"]
 ,Para [Str "Wassup?"]]]

when read as pandoc markdown. Isn't that what you mean?

[Drezil]

Oh, i was not aware that this is the supposed syntax for creating AST-divs in pandoc-markdown as it is plain html and nothing "markdown-y".
According to the "original" html should just remain plain html inside markdown and not be handled in a special way.

One thing that bothers me is that this adds redundancy for the attribute-syntax {#id .class key=value} that is present in everything else.. (link, span, image, ..)

With that knowledge the PR is for me personally from "urgent" down to "would be nice to have it soon".

[mb21]

"would be nice to have it soon"

Indeed, and that's why it has been "soon" for 6 years now..

[Drezil]

Would it be ok to merge this as an extension? I could rewrite it so that "soon" is not another 6 years... :/

Another small thing for http://pandoc.org/MANUAL.html#non-pandoc-extensions probably?

[jgm]

You picked one of the many syntax ideas in that thread. I'm not sure why you picked that one, but I myself wouldn't favor any syntax that makes you write div.

I think there are also some potential syntax issues, assuming we allow "laziness" for the side-marked version (which we probably should since blockquotes allow it). With laziness,

; --- div {.foo}
Lorem ipsum dolor sit amet, consectetur adipiscing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam.

by itself is equivalent to

; --- div {.foo}
; Lorem ipsum dolor sit amet, consectetur adipiscing
; elit, sed do eiusmod tempor incididunt ut labore et
; dolore magna aliqua. Ut enim ad minim veniam.

But then that creates a kind of ambiguity in cases like

; --- div {.foo}
Lorem ipsum dolor sit amet, consectetur adipiscing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam.

; --- div {.bar}
Lorem ipsum dolor sit amet, consectetur adipiscing
elit, sed do eiusmod tempor incididunt ut labore et
dolore magna aliqua. Ut enim ad minim veniam.
; ---                                                                                                                                                                                                                                       
                                                                                                                                                                                                                                            
; ---  

Anyway, this isn't the place for discussion of the syntax; that should take place on the issue itself. I'm just explaining why I'm not keen to merge this at this point, even as an extension.

[jgm]

I should also add that tests of the new feature would be a necessity before I'd even consider merging a PR like this. (I'm not saying to add tests, though, because as mentioned above I have too many reservations about the syntax you're implementing.)

[tarleb]

I'm closing this, as a different syntax has been chosen; #168 is closed.
Thank you for contributing! 👍