Table Markdown doesn't render properly (renders just as text)

Feedback source

None

GitHub Copilot plugin version

0.14.0

Eclipse IDE and version

Version: 2025-12 (4.38.0) Build id: 20251204-0850

Platform

Windows 11

Steps to reproduce

Prompt: Output a comparison of web components vs plain vanillajs in a table to build a simple visual toggle.

Any prompt resulting in a markdown table being output will generate the same issue

Logs (optional)

No response

Expected behavior

A proper table should be visualized

Actual behavior

The plain-text version of the table markdown is shown.

| Aspect | Plain Vanilla JS | Web Components | |--------|------------------|----------------| | Setup | Find a DIV, attach handlers directly | Define a custom element class, register with customElements.define() | | HTML Usage |

with classes | Custom element name conveys meaning |

Additional information

No response

Upstream issue: eclipse-mylyn/org.eclipse.mylyn#364

Sheng Chen (@jdneo)

Sheng Chen (@jdneo): see eclipse-lsp4e/lsp4e#1488.
That would add commonmark to tm4e.

Andrey Loskutov (@iloveeclipse)

Andrey Loskutov (@iloveeclipse) Thank you for sharing this information.

Seems that it's using the HtmlRenderer. We are now using MarkupViewer from mylyn.

I'll do some experiments on that.

Further, it doesn't insert linefeeds between lines, so copy/paste is more painful than it should be

any update on this?

I did not yet start investigating this, but this could be an interesting issue. I'm wondering if Copilot for Eclipse could use commonmark (instead of mylyn.wikitext) like LSP4E and use the tables extension and what effort is needed for the migration. It works pretty much the same with flexmark-java, which I'm already somewhat familiar with.

Dietrich Travkin (@travkin79)

Dietrich Travkin (@travkin79) The context is mylyn.wikitext only support standard markup grammar, but the table rendering is out of this scope, it is an extension of the language, so we cannot render the table now.

Benefit of using mylyn.wikitext is that we deal it as a runtime dependency, so we will not distributed that as a lib. Since commonmark is not embedded in Eclipse, so we need to add it as a 3rd party dependency, some legal/IP check is needed from our side. (Though seems like it is BSD licensed, so should be ok)

Sheng Chen (@jdneo)

Hello Sheng Chen (@jdneo),
Thank you for clarification. Do you think, it's worth trying the migration to commonmark (checking which effort and consequences we have to expect)? Do you want to perform the legal/IP check first?

In principle, we could ask the commonmark developers to also (automatically) publish an Eclipse feature and update site with the commonmark library bundled as an OSGi bundle. I've done that already for the PlantUML library. This way, commonmark could be a runtime / plug-in dependency similar to mylyn.wikitext today.

Sheng Chen (@jdneo)

Update:
After some experimenting with commonmark in copilot-for-eclipse, I have the following findings:

commonmark is available as an OSGi bundle / Eclipse plug-in, so we don't need to bundle the library in copilot-for-eclipse, it can also be a runtime dependency (see update sites like https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2025-03/ and https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/release/latest/)
It's pretty easy to generate valid HTML code with tables from given Markdown using commonmark, adapting ChatMarkupViewer.computeHtml(String) is basically enough
The chat view tries rendering the given HTML code with HTML tables, but it doesn't really support rendering tables. The MarkupViewer is based on StyledText widgets. For that reason, applying CSS styles doesn't work if we just add them to the HTML document's header (e.g. adding a border). Besides, the table cells are not aligned as we would expect them to be. It very much looks as if we need to switch from MarkupViewer and StyledText to org.eclipse.swt.browser.Browser for real HTML rendering. But that's significantly more effort and I'm not sure yet about the things we could loose this way.
Besides rendering tables in general, there are some details to consider like escaping or special handling of code like <table>, `<br>`, or `| --- |`, see example below.

In case, someone wants to see the experimental changes, you'll find them in this branch: https://github.com/travkin79/copilot-for-eclipse/tree/fix-64-table-rendering

Example:
Displaying a copilot answer like the following Markdown code results in the following rendering result.

 | Dialect | Table rendering? | Header required? | Multi-line cells? | Key notes |
|---|---:|:---:|:---:|---|
| CommonMark (core) | No — not part of the spec | N/A | N/A for core tables; use HTML for multi-line cells | Tables are not defined in core; use HTML <table> which allows multi-line/block content inside cells. |
| GitHub‑flavored Markdown (GFM) | Yes — pipe-style tables supported | Yes — separator row required (e.g. `| --- |`) | Limited — no multiple paragraphs; use `<br>` or HTML for true multi-line/block content | Alignment via `:` in separator; inline Markdown works in cells but block-level content (multiple paragraphs, fenced code blocks) is not supported in pipe tables — use HTML tables for that. |
| GitLab‑flavored Markdown | Yes — pipe-style tables supported (GFM-like) | Yes — separator row required | Limited — similar to GFM: single-line cells only; use `<br>` or HTML for multi-line/block content | Very similar to GFM; exact behavior can vary by GitLab version and renderer.

In a web browser the table is rendered as:

FYI: Sheng Chen (@jdneo)

Dietrich Travkin (@travkin79)

Dietrich Travkin (@travkin79)

Thank you for the detailed sharing, looks promising.

I like the solution to make it as a runtime dependency, and since it's download site is https://download.eclipse.org, this should not be blocked by the company firewall usually.

Just one further question: Did you observe any kind of perf downgrade/improvement on you side after switching to commonmark solution?

Sheng Chen (@jdneo)

Hi Sheng Chen (@jdneo),

I did not compare the performance yet, since the implementation is not final. But I did not observe any significant performance changes while testing/debugging with a launch config.

I think, it's worth investigating a slightly different approach, i.e. implementing a Browser widget for real HTML rendering. Otherwise, tables are not rendered as grids, at the moment the table cells are rather rendered as "text snippets in flow layout". But migrating to Browser widget could become complex when coping with CSS styles. Besides, if going with Browser-based widgets, it might be beneficial to have one Browser widget for the complete conversation instead of multiple widgets for requests, answers, etc.

I think, it's worth investigating a slightly different approach, i.e. implementing a Browser widget for real HTML rendering. Otherwise, tables are not rendered as grids, at the moment the table cells are rather rendered as "text snippets in flow layout". But migrating to Browser widget could become complex when coping with CSS styles. Besides, if going with Browser-based widgets, it might be beneficial to have one Browser widget for the complete conversation instead of multiple widgets for requests, answers, etc.

I'm also thinking about using a webview for the chat view, but this could be a very large refactoring.