Add stylesheet support for the viewer // 2.0 fork

[grosenberg]

Viewer updated to recognize stylesheets.

Preferences added to select a default stylesheet from between multiple builtins and a custom stylesheet located on the filesystem. See MarkdownPreview#getMdStyles for the prioritized selection logic.

Also enabled viewer updates to occur without changing the vertical position of the viewer document.

Updated to Java 1.8 and did a bunch of minor cleanups.

[paulvi]

Hoping to hear from Daniel @winterstein before merging

[paulvi]

Updated to Java 1.8 and did a bunch of minor cleanups.

well this make this not so clean PR

[grosenberg]

Why is this a problem?

[paulvi]

Just try to read https://github.com/winterstein/Eclipse-Markdown-Editor-Plugin/pull/72/files as if you were other guy

[grosenberg]

What other guy?

[winterstein]

Hello Paul and Gerald Sorry, I'm not up to speed on this thread. I gather there's an issue with integrating Gerald's new code (and thank you Gerald for contributing). Is it that the new code requires Java 8? If so, would it be possible to replace the Java 8 bits for compatibility. If a decision is required, then @paul - please act as you see fit. Kind regards, - Daniel

…

On Thursday, 24 November 2016, Paul Verest ***@***.*** ***@***.***');>> wrote: Just try to read https://github.com/winterstein/Eclipse-Markdown-Editor- Plugin/pull/72/files as if you were other guy — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#72 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPmsKgd3A32VycYLJmylEDauhMpqOSrks5rBazagaJpZM4K5GNI> .

-- -------------------------------------- Dr Daniel Winterstein Director Edinburgh +44 (0)772 5172 612 http://sodash.com http://sogrow.co.uk

[grosenberg]

Travis is compiling the code, despite all attempts to the contrary, against JDK1.7. The code itself is likely to be 1.6 compatible; certainly no essential bits require more. I am compiling for 1.8, as that is my default.

Note, Eclipse Neon itself requires JDK 1.8. My understanding is that Eclipse generally considers running itself at any lesser level as a bug and security risk. Inferentially, this should extend to plugins.

Not aware of any current Eclipse or other major branded Eclipse platform that is not at the 1.8 level.

I publish a variety of plugins used on Eclipse and other branded platforms, all now requiring 1.8, and have yet to receive any report of an issue.

Are there any known -- as opposed to merely perceived -- platform compatibility problems with a 1.8 requirement?

Bottom line, I strongly advocate for a 1.8 requirement, but will be flexible, particularly if there is an actual platform compatibility issue.

[paulvi]

@grosenberg It is simple: with Java 8 requirements this plugin will work in only Eclipse Neon+
While currently it works in any Eclipse.

If you are so opinionated about how to do all things, adding features, changing versions an binaries at the same time, why you just talk over this project as both me and Daniel don't have much time to move it forward.

Just do however you want, and publish. Eclipse users may choose which one to install.
The worst that can be, is when it is not enough better than current one, and users will be divided which one to install.

Currently if we are to merge this PR, we signing to handle possible head-ache to fix possible bugs.

What do you think?

[grosenberg]

Java 8 was first released on March 18, 2014 -- almost 3 years ago. Neon, released more than a year ago, Kepler and Mars all run just fine with Java 8.

This PR does not require you or Daniel to do anything. Feel free to completely ignore it if you wish.

[grosenberg]

markdown.editor.site-1.3.0-SNAPSHOT.zip

Archived P2 site for v1.3 alpha. Largely feature complete. Runs cleanly (so far).

Intended to provide a convenient basis for review, testing and discussion.

---

Features:

• updates MarkdownJ to 0.4 (current)
• adds 3 additional builtin converters: commonmark, pegdown, and txtmark
• issue Errors in syntax highlighting (e.g. _) #5, Underscore symbol breaks text #8, Add support for internal anchors #17, Image inside a link produces invalid HTML in preview #22, discussion with mylyn #28, Update to markdownj-0.4 #38

---

• adds preference selectable stylesheets
• includes 7 builtin styesheets
• also allows user selection of a custom stylesheet from the filesystem
• issue custom css file #70

---

• builtin preview now shows editor changes in real time
• added update rate limiter
• scroll position remains fixed during updates and without redraw flicker
• preview closes automatically on last Markdown Editor close
• issue Markdown Preview Window scrolls to top when text edited #3

---

• adds spell checking that can be specified/enabled for the Markdown Editor independent of the platform preference specified spell checker

---

• moved the Markdown Editor preference page to the top level
• added spelling, stylesheet and syntax coloring sub-pages

[paulvi]

Java 8 was first released on March 18, 2014 -- almost 3 years ago. Neon, released more than a year ago, Kepler and Mars all run just fine with Java 8.

If a plugin requires Java 8 and is installed in Kepler/Luna/Mars running on Java 7.
What kind of behaviors do you expect?

#72 (comment) Summary is good.

[grosenberg]

Eclipse provides no explicit mechanism for an installed plugin to require a specific Java version. The platform does a check for itself, e.g., Neon will refuse to run with < 1.8.

Given that Travis is using 1.7, the plugin will run equivalently on any platform running on >= 1.7.

That said, the plugin.xml does now specify a 1.8 minimum requirement for developers to build, debug, and publish the plugin.

[paulvi]

@grosenberg

f a plugin requires Java 8 and is installed in Kepler/Luna/Mars running on Java 7.
What kind of behaviors do you expect?

Java 7 JRE will through an Exception unable to read Java 8 binary

http://stackoverflow.com/questions/22489398/unsupported-major-minor-version-52-0

[paulvi]

Now https://github.com/grosenberg/MarkdownEditor is not there

All the talks (and possibly work on code) are in vain