Repository navigation
Table Markdown doesn't render properly (renders just as text) #64
Description
Activity
Upstream issue: eclipse-mylyn/org.eclipse.mylyn#364
Sheng Chen (@jdneo): see eclipse-lsp4e/lsp4e#1488.
That would add commonmark to tm4e.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.
Reacted by Nemanja SimovićFurther, it doesn't insert linefeeds between lines, so copy/paste is more painful than it should be
Reacted by grouvigany 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) 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.wikitextis that we deal it as a runtime dependency, so we will not distributed that as a lib. Sincecommonmarkis 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)Reacted by Nemanja Simović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.
Reacted by DerIngoUpdate:
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
MarkupVieweris based onStyledTextwidgets. 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 fromMarkupViewerandStyledTexttoorg.eclipse.swt.browser.Browserfor 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)
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?
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.
18 remaining items
- added 15 commits that reference this issue
on Jul 20, 2026
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 |
+ initTagManager('#myTags') | | | Style Isolation | None—CSS can bleed in/out, must use unique class names | Shadow DOM provides full encapsulation | | Reusability | Copy/paste JS + CSS, call init function | Just use the HTML tag anywhere | | Form Integration | Manually create/update hidden input | Same, or use ElementInternals API | | Dependencies | None | None | | Browser Support | All browsers | All modern browsers (IE11 needs polyfill) | | File Structure | Separate JS + CSS files, or inline | Single self-contained JS file | | Initialization | Explicit: TagManager.init(element, options) | Automatic: element self-initializes when added to DOM | | Multiple Instances | Must call init for each instance | Just add multiple tags | | Configuration | Pass options object to init function | Use HTML attributes: | | Event Handling | Custom callbacks or manual event dispatch | Native CustomEvent dispatch, use addEventListener | | Cleanup | Manual: must track and remove listeners | Automatic via disconnectedCallback() | | Learning Curve | Low—standard DOM manipulation | Medium—must learn lifecycle callbacks, Shadow DOM | | Debugging | Straightforward DOM inspection | Shadow DOM adds a layer in DevTools | | Framework Compatibility | Works anywhere with minor integration | Works anywhere as native HTML element | | Code Size | Minimal boilerplate | ~20-30 extra lines for class structure | | Attribute Reactivity | Manual: watch for changes yourself | Built-in: attributeChangedCallback() | | Semantic HTML | GenericAdditional information
No response