Syntax Highlighting inside widget decoration

Is it possible to apply syntax highlighting inside the widget’s content?
For instance I implemented the following Decoration

the code is following

class SubscriptWidget extends WidgetType {
  constructor(readonly rawValue: string, readonly visibleValue: string) {
  eq(other: SubscriptWidget) {
    return this.rawValue === other.rawValue;
  toDOM() {
    let span = document.createElement("span");
    const r = /([^,]+)/;

    const head = this.visibleValue.match(r)[0];
    const substring = this.visibleValue.substring(head.length + 1);

    const sub = document.createElement("sub");
    sub.innerText = substring;

    span.textContent = head;

    return span;

  ignoreEvent() {
    return false;

Would it be possible to apply syntax highlighting to this.visibleValue ?
or even more - recursive widgets/decorations

Not directly using the editor’s syntax highlighting. Though I guess you could run highlightTree on the subtree for the text inside the widget, feeding it the same highlighters that your editor uses, and then construct the highlighted DOM directly and put that in the widget.

1 Like

Thank you, @marijn.
This is a component of @lezer/highlight, right? I am just a bit confused.
and if it is true, then, I can construct something like this (first answer)

You could apply marker widgets to the content you want to alter, and put empty replace widgets on the stuff you want to hide, skiping the whole need to redecorate it inside a new widget.

1 Like

To fully support the recursion for widgets I was thinking, would it be a bad idea to start a separate instances of CM6 view inside the widget? For example of I have a widget of a matrix, where each cell is a separate CM6 editor. Then I can make matrixes inside matrixes and so one :smiley:

How good is CM6 in instancing?

Well. I tried, not too bad I would say

Screenshot 2023-04-13 at 21.10.09

But now, I don’t know how to get rid of blinking cursors.

I am also wondering, how is it possible for CM6 not to bring so much overhead, @marijn. I can’t really feel any performance drop with this approach.