Github markdown processing about idea-multimarkdown

[vsch]

Excellent idea. I could add a tab GitHub Preview. However, currently the real issue with the display is the java HTMLEditorKit that is used in the plugin that creates all the problems. It is only HTML 3.1 and even then not everything is implemented.

I will search to see if there is another Java or JVM compatible option for rendering HTML that is closer to browser rendering than HTMLEditorKit.

As it is I have to go through hoops to get decent display control, with limited success. If it was standard HTML and CSS life would be so much easier. I could then get GitHub to process the markdown and display it in a separate tab.

I would still keep the parsing in house because it is needed for syntax highlighting and navigation. The latter I am planning on implementing in the near future. GitHub won't help with these but the HTML generation for preview is an excellent idea.

I will definitely look into it.

Thank you.

[vsch]

Here is a preview of the upcoming release of the plugin with javafx WebView for the preview tab. Feast your eyes, if you like GitHub's look. The down size is that it will need the IDEA to run on JDK 1.8:

[trevjonez]

no down side at all. I already use 1.8, 1.6 on OSX is broken (DH keypair issue) so i just went straight to 8
Looks way good!

[vsch]

Same here. I am working with EAP and Oracle jdk 1.8.51. Some people are afraid to move but I can no longer support the HTMLEditorKit code. It is a beast to work with with nothing to show for the effort. I got "WebView eating out of my hand" after about 20 hrs of porting and figuring out how to make it do what I want and how I want it. I love it. Page updates keep scroll information. Mail links open your mail app. Images display correctly. CSS works. JavaScript works, etc. One more release for jdk 1.6 and after that only 1.8. BTW, I tried running IDEA 13.1 on jdk 1.8 and the plugin works fine there too.

[vsch]

@trevjonez, version 1.1 is released. Let me know what you think.

[trevjonez]

I downloaded the update last night and need to do some component architecture outlines today so we shall see shortly.

[crazyfrozenpenguin]

Tables are not yet supported

[vsch]

@crazyfrozenpenguin you need to enable the markdown table extension, and probably a whole bunch of others, in settings. Here are the settings I use for maximum GitHub compatibility:

[crazyfrozenpenguin]

Thanks! It was enabled.

The issue was that I was using a '-' in on cells. For example:

| Header 1 | Header 2 | Header 3 |
| --------- | --------- | --------- |
| 123456789 | -         | 123456789 |

The above table does not render the line. I was able to get around it by escaping the character.

| Header 1 | Header 2 | Header 3 |
| --------- | --------- | --------- |
| 123456789 | \-         | 123456789 |

Escaping the character should not be required. It works just fine in other markdown editors.

[vsch]

@crazyfrozenpenguin thanks for the clarification. Your are right. It is a pegdown markdown parsing issue. I am looking into it.

created a separate issue #53 for this bug.

[vsch]

@crazyfrozenpenguin the pegdown bug is now fixed. The issue will be resolved in the next release. BTW, I opened a separate issue for your bug report. #53

[vsch]

@trevjonez, I don't know if you still feel that this feature is required but it has a few draw backs:

1. much more difficult to instrument the HTML: for scroll synchronization which I am planning to implement, same for scroll position preservation as is done now
2. JavaFX WebView has fragility issues, may crash in the native libraries closing down the IDE. Right now if the issue is known it can be mitigated. If rendering is done by GitHub then it makes it more difficult
3. The feature is already implement in GFM plugin without the JavaFX WebView limitations by using chromium engine.

I started writing this reply yesterday and decided to give JavaFx display of GitHub pages a whirl, just to make sure. Not bothering with document processing on GitHub, just using URL to the corresponding remote page. Liked the initial results. It does make it more convenient to validate the final page without having to click and have the browser come up.

I would not want to have to go through GitHub for rendering every modification. So I came up with a compromise: display the GitHub website page for the current document if the document is not modified and has been committed. It is an experimental feature with the following limitations:

1. No attempt is made to validate whether it has been pushed to the remote other making sure the current branch has a corresponding remote. The plugin assumes that the remote is GitHub, did not try with other configurations.
2. Clicking on links will either do nothing or if the link resolves to a file in the project will open that file in the IDE. Reason being is that letting JavaFX out into the wild can cause crashes. I originally let the clicks be handled by WebView but managed to crash my IDE. So now disabled allowing clicks to uncontrolled links. Doing a search will still display the results but following links or clicking buttons will not work or will open the file in the IDE.
3. Any modifications to the file will revert back to the local rendered version. After commit the remote page will be displayed.

If you have not objections I will close this issue since I do not see implementing general processing of documents on GitHub beyond displaying its version of the page.

[trevjonez]

Yes you wouldn't want to do every modification. Though if the concept continues you may be able to just buffer the refresh rate to only once every 30-90 seconds with an optional manual refresh? The other part is I believe if you don't authenticate with the github API they have a pretty hard limit on how much they will render within a time period.

[vsch]

The 30-90 seconds would only be acceptable for someone who mostly reads and not writes documents, so they don't need this plugin at all and can get by with GFM.

In the end I do not see major advantages for going with GitHub rendering but a lot more support hassles and limitations. This route makes sense for GFM because it has no parser or editing support. In the case of idea-multimarkdown, I have to have full parsing for the rest of the functionality. Serializing the HTML is the easiest part of the job.

With ability to see the document on GitHub when you commit and push your branch should be sufficient for most users.

[trevjonez]

Sounds good. The move to javafx made this SO nice to use. Really met all of my needs I felt lacking when I opened this request

[vsch]

@trevjonez that is what I thought. The next release adjusts the links in the preview for the current branch you are on. So after a commit and push you can follow the links or the
book icon in the header and instead of always taking you to master branch it will take you to the page on GitHub for the current branch you are on.

Or you can enable the "Show GitHub Page" feature and after a commit, the preview will show the GitHub page by default.

I will be adding a toolbar button and an action so you can switch without opening preferences.

While editing it will look as always:

After a commit switches to showing the actual GitHub page

As soon as you modify the document it switches back to plugin rendered preview.