Update to markdownj-0.4

[paulvi]

MarkdownJ 0.4 has been released.

https://github.com/myabc/markdownj/releases/tag/markdownj-0.4

And Alex Coles @myabc is doing a lot of refresh and updates.

[paulvi]

@winterstein How to use alternative markdown->html converter ? ref #17

[victorsegall]

@paulvi, from my off-topic in #17

Turns out that it's simple.

The pandoc binary is already defaulting to output on stdout, when its not given -o flag, but this Eclipse plugin is not coded to handle variables on the configurable command line option. The solution is a middle-man script, the following being the minimum Windows Batch example:

@echo off
C:\Users\username\AppData\Local\Pandoc\pandoc "%*" -f markdown -t html

Then give the full path for that script to the Eclipse plugin.

If you don't silence the input echos, you'll see (on the Eclipse Markdown view) the argument being passed in:

C:\eclipse>C:\Users\username\AppData\Local\Pandoc\pandoc C:\Users\username\AppData\Local\Temp\tmp2035521915180482124.md -f markdown -t html 

I also used the following to quickly prove that the plugin's preview building routine is called even when the Markdown view is not shown (I removed the view from all perspectives), as I remembered that you asked about this in relation to performance impact of regenerating previews while editing large files:

@echo off
set curTimestamp=%date:~7,2%_%date:~3,3%_%date:~10,4%_%time:~0,2%_%time:~3,2%
C:\Users\username\AppData\Local\Pandoc\pandoc "%*" -f markdown -t html
@echo %curTimestamp%>> C:\Users\username\.log\eclipse-pandoc-preview.log

The preview routine is called very frequently. There is no checking for document changes; it simply rebuilds the preview every time one of the triggering UI events occurs. Generally speaking, that is any time that the file editor gains and then loses focus (switching cursor focus between views), and when the file is saved.

It's also rewriting its tmp*.md file every time. The numeric component of the file name is random, and the file is deleted at the end of the preview routine if that routine succeeds. If you provide a command line option to the plugin which causes it to output an error on the Markdown view, it will leave the tmp*.md file on the disk.

So, (without having seen code yet) the logic behaves like it's doing:

1. Bound UI event triggers preview function call
2. Preview function writes tmp*.md from Eclipse editor buffer (memory) to disk
3. Call the preview generator with tmp*.md as source file argument
4. Receive generator output on stdin, with exit code 0 (non 0 exit code from the generator binary causes an exception throw in the plugin)
5. Delete tmp*.md from disk
6. Send received output to Eclipse browser view (appears to be doing the equivalent of document.write() on "about:blank" page

All of that considered, pandoc is possibly a faster option than MarkdownJ for this case as-is. It really depends upon whether or not the code is doing steps 2 and 5 (the disk writes) when it uses MarkdownJ, and how performant MarkdownJ is for large files. I doubt that it beats pandoc, but if the disk writes are absent, then that might make up the difference.

[paulvi]

That has been good work done.

And there are many other issues.

I can't comment on details, welcome with PR. Or if you don't go on with code changes, please modify README online to show some tips or just add to wiki https://github.com/winterstein/Eclipse-Markdown-Editor-Plugin/wiki

@winterstein @tbrugz @oliviermartin please look in