Different renderings comapared to original marked.js or github style

[doortts]

Hi~ thank you for your markedj lib. : )

I'm trying to use it, but I have found some different rendering results.

Tested strings are

Message A
- list A
- List B

markedJ results is..

github or marked.js rendering is

Message A

• list A
• List B

Is it bug? or do I use it wrong?

[McFoggy]

Depending on the interpretation of markdown syntax ; It can be seen as corrrect.

StaackEdit editor also react like that

while Dillinger is more permissive

If you look at both default documents in each editor they have a blank line to separate a paragraph from the list.

[doortts]

@McFoggy Thanks for explanation. : )
But markedj author described at the README like this

JVM port of graceful markdown processor marked.js.

and rendered results is different from marked.js.
So, I left this issue.

[McFoggy]

@takezoe and what do you think about embedding marked.js inside a java wrapper.
Have a look at my fork branch issue-8 where I have indeed a Junit test demoing that this reported issue works with marked.js embedded in the JVM.

Now that nashorn (JRE javascipt engine) is very efficient and compete with V8, such solution become feasible.
Thus maintenance cost is very low, just follow marked.js releases.

For this specific problem in the java version, I think the Grammer#BLOCK_PARAGRAPH lacks somehow an exclusion for a BLOCK_LIST that could follow ; but modifying those regexp is not very easy.

[takezoe]

@McFoggy markedj is not simply JVM port of marked.js. It is an extendable markdown processor for Java and other JVM based languages.
In fact, GitBucket is overriding some methods of markedj's Renderer:
https://github.com/gitbucket/gitbucket/blob/master/src/main/scala/gitbucket/core/view/Markdown.scala

And in my experience, Mustache.js on Nashorn has made memory leak. It was a troublesome problem which makes off-heap leak. So I would like to avoid to introduce Nashorn quickly.

I know that maintenance of markedj is much painful. However I think this cost is meaningful to pay for GitBucket and other applications on JVM.

[McFoggy]

It makes sense, was just an off proposition in case you did not thought about it. In the past with rhino especially embedding javascript was not a solution for real time but nashorn is far more better now.

[doortts]

Also, I had some test about nashorn with marked.js. I found that It has some problems compared to rhino. especially wrong translations of regex. And Nashhorn is fast for read but slower for hash input. So I had to back to rhino.

[making]

@McFoggy

what do you think about embedding marked.js inside a java wrapper.

Marked4j is a kind of your proposal lol
https://github.com/making/marked4j