Feature Request: Persistent Decorations/Widgets for Tables (Out-of-Focus)

[Xoppyc]

Feature Request: Persistent Decorations/Widgets for Tables (Out-of-Focus)

Description

First off, I want to say that I absolutely love this library! It is easily my favorite (and first =) ) GitHub star. The work you’ve done here is beautiful, and I’m hoping to be in a position to donate soon to support the project.

I am currently using a custom extension passed into the markdownTables() configuration to remove "Markdown bloat" (raw syntax) and add decorations. However, I’ve noticed a limitation regarding how decorations are rendered.

Current Behavior

• Custom decorations and widgets only appear to trigger when the cursor is actively inside a specific cell.
• When the cursor leaves a cell or the table entirely, the table reverts to the default CodeMirror Markdown syntax highlighting.
• The "un-bloating" effect is localized only to the active cell.

Desired Behavior

I’m wondering if it is possible (or intended) to have these decorations/widgets persist even when the cursor is outside of the table. Ideally, the table would maintain its "cleaned up" look regardless of where the focus is in the document.

Questions

1. Is the current "focus-only" rendering an intended design choice for performance?
2. Is it realistically possible to implement persistent decorations for the entire table through the current markdownTables() config?

Keep up the amazing work!

[ckant]

Thanks for the kind words!

Is the current "focus-only" rendering an intended design choice for performance?

Yeah, it's intentional for performance reasons. Each cell actually has two different representations. There's the cell editor that shows when the cursor is inside the cell and the cell view that shows otherwise.

The cell editor is a full CodeMirror editor which applies all the extensions from the config. The editor is created on-demand when a cell is selected and it's discarded when it's deselected. So there's only at most 1 cell editor active at any time.

The cell view is html created by running the cell text through the CodeMirror markdown parser and syntax highlighter. It's recreated whenever the cell changes.

So that's why the cells don't show your decorations when they're not selected. The cell view doesn't run the CodeMirror editor or the extensions. It just adds the CSS classes from the syntax highlighter which makes it look (mostly) similar to a vanilla CodeMirror editor.

Is it realistically possible to implement persistent decorations for the entire table through the current markdownTables() config?

Currently, no. The config has no options that can influence the rendering of the cell view mentioned above.

---

I had originally experimented with using a CodeMirror editor to render the cell view, but ran into issues. From what I can recall, I wasn't able to get it to render all cells quickly and performantly.

CodeMirror is optimized for lazily parsing and rendering documents based on which lines are currently visible in the browser viewport for performance reasons. It really doesn't want you to render stuff off-screen or do stuff eagerly.

I had tried to render the full table and extract the html from each cell, but I believe it was too slow, unreliable, and resource intensive. This was especially true for larger tables. That's when I started looking into mimicking the html instead. That ended up being fast and reliable since the CodeMirror parser and highlighter can be run eagerly.

Another option would be to render each cell in isolation, but I think that would run into the same core issues. I also thought about rendering each cell as a single line in a document.

---

So there seem to be two possible paths forward:

1. Use a full CodeMirror editor to render unselected cells
   1. Use CodeMirror decorations to customize appearance
2. Add an extension point to customize the appearance of unselected cells
   1. Expose some custom hook into the rendering process

(2) is annoying since you would have to duplicate your extension/decorator logic.

Ideally (1) would be the solution, I'm just not confident it could be performant, despite caching. Some graceful degradation may help (use (1) and fallback to the current behavior for very large tables). Will take another look 👍.

[Xoppyc]

Thanks for the insight! It’s interesting to see how the Cell Editor and Cell View distinction works

I’ve been thinking about potential middle grounds, and perhaps a tiered approach could work:

1. A configuration toggle: Let users explicitly enable 'Always Active' editors via a boolean in the table config. This follows your Path 1, putting the performance vs. aesthetics choice directly in the developer's hands.
2. A lightweight HTML parser: For the 'Cell View,' we could use a simplified Markdown-to-HTML parser. Since table cell syntax is usually restricted, a lightweight parser could map basic MD to standard HTML tags. If those tags share the same CSS styles as the editor, we get a consistent 'cleaned up' look without the overhead of a full CodeMirror instance.

Providing these as Lightweight/Heaier/High Fidelity options might be a pretty flexible approach.

[ckant]

I was poking around at the CodeMirror code and I think there might be a middle ground similar to the HTML parser method.

I'd like to have decorations that hide the Markdown be an extension point rather than an included feature, since there are so many different ways this can be done. For example, each CodeMirror-based editor I've seen has a slightly different way to show inline links and images.

They all use replace decorations to hide the content, as you've done above. I'm thinking I could accept a subset of the decoration API to emulate the rendering for the Cell View.

Decorations are normally either precalculated and passed as a DecorationSet or calculated from a view (view: EditorView) => DecorationSet.

Since there is no actual EditorView for a Cell View, the next best thing is the text (cell text) and the syntaxTree (cell text syntax tree). Decorations in the wild seem to either run regexes against the text or iterate over the syntaxTree. Editor selection isn't relevant since the Cell View is only shown when unselected.

So essentially something like:

interface MarkdownTablesConfig {
  // ...existing options plus...
  readonly decorateCell?: (cellText: Text, syntaxTree: Tree) => DecoratedRange[]
}

interface DecoratedRange {
  span: { from: number, to: number }
  decorationSpec: ReplaceDecorationSpec | WidgetDecorationSpec | MarkDecorationSpec
}

The code could then implement logic to mimic the way CodeMirror renders real decorations (with some big caveats for simplicity). My goal here would be that the normal editor decorations you wrote above could maybe be reused here and hopefully there would be little duplication of logic needed to implement the decorateCell function.

Still digging to see if there's a better way to tap into CodeMirror's decoration logic.