Offset jump-to-source in RTL text

[emilyyyylime]

Describe the bug When clicking a block of text in a paragraph besides the first block, jump-to-source sends you one block behind where it should.

To Reproduce

• Open a new Typst document in VSCode, with its preview in a split window
• Type some text, then an equation, then other text; example:

  הנה משוואה: $V = I R$. היא מאוד מעניינת

• Click the last part of the paragraph (this is the text on the right of the equation)

Observed behaviour The equation source is highlighted:

Expected behaviour The corresponding source text should be highlighted:

Package/Software version:

VSCodium version:

Version: 1.85.1
Release: 23348
Commit: 08e6c15293922dd53a864bb041be381322fee401
Date: 2023-12-30T16:21:42.781Z
Electron: 25.9.7
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.6.8-arch1-1

typst-preview extension version: v0.10.6

[Myriad-Dreamin]

I copy and pasted your sample to my local file and test it a bit. It probably works in "nightly" typst-preview by the PR https://github.com/Enter-tainer/typst-preview/pull/225. But I cannot really confirm it since the alphabet (I don't know what they are) are all just same in my eye, a bit embarrassed😅.

And you can verify it by downloading and installing the extension pack.

https://github.com/Enter-tainer/typst-preview/actions/runs/7572892637

Download it on your PC:

I'm waiting for a good news that we've solved this issue before you was submitting it. If not, we may look into it at this weekend.

[Myriad-Dreamin]

close since PR #225 is merged and no response.

[emilyyyylime]

Sorry for not responding, the issue is much less noticeable now (especially as clicking on characters in generated pdf isn't that accurate anyways, but it still seems to occur

[emilyyyylime]

This testcase actually shows off some inconsistencies in LTR text as well:

ןןןן \
llll \

Clicking on the leftmost l puts the cursor right after it in the source window; same goes for the next two. On clicking the final l however, the entire source word consisting of ls gets highlighted... except for the last l itself.

When clicking on the leftmost ן (Hebrew Nun, word-final form. Picked arbitrarily), the cursor is put at the very centre, two Nuns on its left and two on its right. The next Nun to its right places the code one character earlier—which is expected, as the text flows right-to-left at that location. The next Nun to the right, and the second one in reading order, brings the cursor to just before the first character of the word, and finally; the first Nun selects all but the last Nun.

When debugging yourself, it will be hard to tell what position in the document your visual cursor corresponds to. This is partially VSCode's fault, but mostly a universal fact of life for bidirectional text users. Two anchors to help you stay on your feet are the column indicator in the bottom right of the editor window, and simply counting the number of times you can click the left/right arrows before exiting the word