Markdown support

[nlisker]

Markdown is a ubiquitous syntax. Adding a renderer or syntax highlighter that shows what the resulting look is would be helpful and, in my opinion, fitting for this toolset. Mylyn WikiText exists, but consider adding your alternative for a more complete solution.

[akurtakov]

This project is built around language servers - so if you know of language server for editing markdown please give us a link to be evaluated. Implementing it as part of this project would mean reimplementing wikitext which would be loss of time for us.

[nlisker]

There is https://github.com/artempyanykh/marksman. If doing this is not worth the work then feel free to close it.

[akurtakov]

That's very interesting and has the potential to outsmart wikitext. IMO it's worth experimenting with standalone eclipse plugin integrating it - once usable it can be offered for inclusion here or to mylyn for easier redistribution. Are you interested in experimenting with it?

[nlisker]

If you mean trying out a development version, then sure.

It also occurred to me just now that in Java 23, docs can be written in Markdown: https://openjdk.org/jeps/467. This means that Eclipse has to be able to show a preview of the docs (it does so for the HTML-based once), which in turn means that maybe the JDT team already has a markdown renderer. I'll try to dig a bit into this.

[nlisker]

The relevant Eclipse issue is eclipse-jdt/eclipse.jdt.ui#1472. Also eclipse-jdt/eclipse.jdt.core#2744. Specifically, the solutions they brought up are Mylyn Wikitext and CommonMark, (eclipse-jdt/eclipse.jdt.ui#1472 (comment)), with the latter existing in Orbit already (eclipse-jdt/eclipse.jdt.ui#1472 (comment)), so they went with that.

Now I wonder if the solution they implemented can also be used for .md files. Needs more digging...

[nlisker]

Here is the reply: eclipse-jdt/eclipse.jdt.ui#1472 (comment).

[mickaelistria]

What are the current issues with Mylyn Wikitext for markdown edition?
I think some of what it's doing (reading the file and adding styles directly on the text) is actually very good, and I don't get what Wild Web Developer could do significantly better.
Can you please elaborate about the opportunities you have in mind?

[nlisker]

Initially I thought it would just avoid the installation of multiple features because the solutions will be concentrated in one place. But now, according to @akurtakov, there is a potential for improvement of WikiText regardless of where it's distributed.

[mickaelistria]

FWIW, we had some discussion with @akurtakov and the outcome is that we simply improved the TextMate themes shipped by TM4E. In the end, the generic editor with latest build of TM4E does a good job, sometimes better than wikitext.

[nlisker]

the outcome is that we simply improved the TextMate themes shipped by TM4E

Can you link to these changes?

[mickaelistria]

eclipse-tm4e/tm4e@3f557fa which can be tried from https://ci.eclipse.org/tm4e/job/TM4E/job/main/lastSuccessfulBuild/artifact/org.eclipse.tm4e.repository/target/repository/

[sebthom]

@nlisker In combination with the TM4E/Generic Editor you can additionally install https://github.com/sebthom/previewer-eclipse-plugin which can render (GitHub Flavored) markdown.

[laeubi]

@sebthom very interesting plugin! what I'm wondering is if it is somehow possible to integrate it with the generic editor to show an additional Preview tab?

I'm currently using a markdown editor that show it like this:

and find it quite handy, this is also like its done in Github UI and many other editors. It could also be useful with an HTML editor.

@mickaelistria I think it would be very useful if the preview feature (extension point + view) would be part of generic editor at platform so the plugin of @sebthom can plug into this (and others maybe as well).

[mickaelistria]

I don't think that the proposal with a preview editor tab is actually as interesting as a dedicated view. I remember I had considered that when doing an old "Draw2d preview" that was capable of rendering the figure that's being coded; and ended up convinced that a preview view is drastically better and that preview tabs on editor are somehow an antipattern.
And the reason why I think a separate view is better is that one may want to see the effect of their change as they type without having to switch between tabs. A "Preview" view works better for that as it can react to change on the current text editor immediately without need for any action.

[laeubi]

A separate view has the disadvantage that I need double the space to show both and I always can only preview one document at a time.

Such feature do not needs to be exclusive and different user might use different ways (and one can even have a preference to switch the preview tab on/off) so one can offer both ways.

In any case I think the preview feature would be something that should be shipped by default with generic editor.