The RTL Support plugin breaks markdown tables

[Aspect004]

I made sure that the problem is not with Obsidian itself, it's the RTL Support plugin.

Steps to reproduce

Step 1: Create a markdown table.
Step 2: Add 2000+ words to individual cells or even to one cell.

Additional information

Here’s a video showing the problem exactly: Video showing RTL Support bug

[m-primo]

I can confirm I have the same issue.
It made me go insane and never expected it would be from this plugin!
I hope it get fixed soon.

[esm7]

Thanks, will get it fixed!

[esm7]

Thought it's worth dropping an update here, so you all may know that in spite of struggling with this quite a bit, I'm still puzzled about what causes this.
Basically it seems like inserting CodeMirror decorations (which are the HTML attributes used to control the line directions) to tables that include long texts, causes a RangeError from within Obsidian code when stepping over empty cells:

Uncaught RangeError: Position 1 is out of range for changeset of length 0
    at e.mapPos (app.js:1:261503)
    at vt (app.js:1:298283)
    at e.compare (app.js:1:294667)
    at t.update (app.js:1:353789)
    at e.update (app.js:1:443717)
    at e.dispatchTransactions (app.js:1:440278)
    at e.dispatch (app.js:1:442266)
    at t.set (app.js:1:1394187)
    at new t (app.js:1:1418386)
    at t.editTableCell (app.js:1:1413221)

In spite of trying a few directions of investigation and workarounds, I'm still unsure why this happens. It might even turn out to be an Obsidian bug. I'll continue to investigate and possibly reach out to the Obsidian devs if needed.

[Limezy]

Have you had any luck on that one ?

[esm7]

Unfortunately not, I tried everything I could but it seems to be failing deep inside Obsidian code -- just somehow (I guess indirectly) caused by the addition of extra direction attributes. I contacted the Obsidian devs about it but received no reply yet :-/

[Limezy]

It looks like the new Obsidian 1.7.4 has solved the issue ?

[esm7]

For me it hasn't :(

[Limezy]

Indeed, I was too quick testing and had a false joy...

Don't know if it helps the debugging but in fact edition works for one of my cells that has a <span lang=he type="paragraph" xxxxx </span> inside.

[whitenoisedev]

Please, open a thread here, describe the problem and provide a minimal reproducible example if possible. Thanks.

[esm7]

Just for reference, the thread is here.

[Bacham]

I can confirm I have the same issue, Obsidian 1.7.7.

[kotaindah55]

The key problem is, from now on, in the live preview mode, each table cell will create its own EditorView when you click on it. Thus, it's probably conflicted with the decorations that have been built based on the root view.

app.js:1 Uncaught RangeError: Position 151 is out of range for changeset of length 2
    at e.mapPos (app.js:1:264441)
    at Ct (app.js:1:301303)
    at e.compare (app.js:1:297687)
    at t.update (app.js:1:358349)
    at e.update (app.js:1:456858)
    at e.dispatchTransactions (app.js:1:453296)
    at e.dispatch (app.js:1:455407)
    at t.set (app.js:1:1652995)
    at new t (app.js:1:1680491)
    at t.editTableCell (app.js:1:1675191)

As we can see, Position 151 is the start offset of the viewport, and length 2 is the doc length of the table cell view. Because, it happens when the first line of the root view is not within the viewport range, and the table cell only has two characters for instance.

[kotaindah55]

You can use this.view.state.field(editorEditorField) to retrieve currently active EditorView, instead of using this.view.state.field(editorInfoField).editMode.cm. It includes the one in the table cell. You can still use editorInfoField to gather MarkdownView informations. And for me, it fix the crash.

Hope it can give some help...

[esm7]

@kotaindah55,

Would you mind expanding on the above? I tried replacing the instances of obtaining EditorView objects into -

const editorView = (view.editor as any).cm.state.field(editorEditorField);

But it did not seem to make any difference.
You seem to refer to the usage of editorInfo inside the constructor EditorPlugin, but I'm unsure why that's the place to be changed, since this is already where a view was given to the editor plugin, and it seems too late down the chain. Doesn't this function already hold the active EditorView (that's what the view variable is about)? I'm confused, and if you got it fixed, I really want to know how.