You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, in other words, you first see the cursor is on the row 50, after applying the patch/formatting, you observe the cursor is now on row 40. You modify vy so that the distance from the top of the viewport to the cursor (the row_offset) does not change.
The second problem is where the cursor actually lands or ideally should land after applying the patch. That's a problem you cannot solve under all circumstances. (That's why Prettier can - given a cursor position - return the new cursor position; computed as part of the formatting job.)
Doing a diff is probably a good approach. Iirc, you only have to "fix" the cursor if you replace (including expanding or shrinking) a region where the cursor is in ("contained") or at ("at the edges"). This is of course always true if you replace the whole buffer.
From my understanding, it would be enough to diff the text up to the line the last cursor is on. Then compute the new cursors using the diff, replace the whole view, and set the new cursors.
You could also apply the diff hunk by hunk, t.i. calling replace et.al. multiple times. As Sublime controls the cursor just perfect as long as the replaced region does not own a cursor, you only have to "fine" diff a hunk iff it contains one of the cursors which should be a good speed up computational-wise.
That's an unrequested wall of text. Take what you want out of it.
Regards
The text was updated successfully, but these errors were encountered:
Hi!
I read https://discord.com/channels/280102180189634562/280157067396775936/840207551065096284 and the linked issues, for example sublimehq/sublime_text#4144
From my experience working on GitSavvy and SublimeLinter you can split the problem to make it more simple.
First, you can stabilize the viewport, just using
This has to be done sync as a
TextCommand
. (see: https://github.com/timbrel/GitSavvy/blob/d6e24d714c08e5b975ae08bafbebb2f75eabe303/core/view.py#L183-L194)This is a good start. However, you might want to improve further by first reading a
row_offset
and reapplying it afterreplace
and setting the new cursor. With therow_offset
you basically measure that the cursor is at the nth row/line, or x pixels, from the top of the viewport. (Refer: https://github.com/timbrel/GitSavvy/blob/d6e24d714c08e5b975ae08bafbebb2f75eabe303/core/view.py#L111-L115)Reapplying:
So, in other words, you first see the cursor is on the row 50, after applying the patch/formatting, you observe the cursor is now on row 40. You modify
vy
so that the distance from the top of the viewport to the cursor (therow_offset
) does not change.The second problem is where the cursor actually lands or ideally should land after applying the patch. That's a problem you cannot solve under all circumstances. (That's why Prettier can - given a cursor position - return the new cursor position; computed as part of the formatting job.)
Doing a diff is probably a good approach. Iirc, you only have to "fix" the cursor if you replace (including expanding or shrinking) a region where the cursor is in ("contained") or at ("at the edges"). This is of course always true if you replace the whole buffer.
From my understanding, it would be enough to diff the text up to the line the last cursor is on. Then compute the new cursors using the diff, replace the whole view, and set the new cursors.
You could also apply the diff hunk by hunk, t.i. calling replace et.al. multiple times. As Sublime controls the cursor just perfect as long as the replaced region does not own a cursor, you only have to "fine" diff a hunk iff it contains one of the cursors which should be a good speed up computational-wise.
That's an unrequested wall of text. Take what you want out of it.
Regards
The text was updated successfully, but these errors were encountered: