Skip inline diff wording when > 10 000 hunk

[stoivo]

fix: #1133

@kaste, This is't perfect but it helps. The SequenceMatcher.get_opcodes call is the slow one in this case When I run it on a file with 30000 charachets with one characher changes it takes 35 sec om my mac book pro. We could "solve" by backgrounding. I dont think is it worst the CPU time even.

If you want to source controll a 30000 character long line manually please split it up. I also this SequenceMatcher uses more time it the are move changes between the lines.

An onther solution would be to use gits --word-diff. SequenceMatcher does a better job at finding the excat characher which changes. Git word-diff is a lot faster but less exact.

ok, fix?

[kaste]

Bail out is okay, it still should run on the worker (even if this process only takes 1 second).

[asfaltboy]

For what it's worth, I get the same issue when committing an ipynb file and have verbose commits turned on...
This PR seems to fix only issue with the diff in ipynb files by bailing out (though I haven't tried 100MB file), but it doesn't touch verbose diff rendering, though, it might be out of scope, and we ought to recommend users to mark such files as binaries in gitattributes

[stoivo]

@kaste I agree.

@asfaltboy is it show_full_commit_info we are talking about. I also have show_full_commit_info enabled. Maybe we should do something similar to what @kaste did on the status view. The async rendering.

[stoivo]

@kaste I did one attemt but It feels like it is flacking which is annoying. Do you have a hint to me?

[kaste]

What exactly do you mean with 'flacking'? On first usage, it should open a new blank view, then do the work in the background, and paint once when it's ready.

[stoivo]

Sorry, flashing. I mean flashing.

Take a look at the screen recoring.
Archive 2.zip
If you look at it frame bye frame there are 2 frames where the text is selectected. On my case it would be pink. Somewhat bright and flashing.

[kaste]

Do you mean such a frame:

I see the flashing, interesting enough in the above picture only the minimap is purplish, the actual buffer looks fine.

[kaste]

Hm, there is no cursor. You should do

         self.view.run_command("gs_replace_view_text", {
-            "text": inline_diff_contents
+            "text": inline_diff_contents,
+            "restore_cursors": True
         })

[stoivo]

This is what I mean, there are like 2-3 frames with each

[kaste]

And the patch I posted ☝️ doesn't work?

[stoivo]

no

[kaste]

Hm, odd, I can reliable reproduce the selection issue you're showing, for the minimap if it is on. I get the whole selection only if the cursor is in block mode (since block mode is new, probably a bug).

But the patch "restore_cursors": True solves this on my Windows. (These are drawing bugs so every OS can have its own bugs.)

Please make sure to restart Sublime bc the reloader doesn't work reliable here.

[kaste]

But keep in mind, it is not okay to always refresh async. Usually only on_activate and on_create. E.g. if we hunk something, we need to block the UI for that otherwise view and state get out of sync, and we probably cannot [hhh]unk anymore (just like what was the case for the diff view).

[kaste]

There are other bugs as well, if you [h]unk just somewhere it will just throw at you. If you [h]unk just on the line before an actual hunk, it will still hunk. But if you [l]ine just before a changed line, it will actually stage the last line (iirc) from that hunk.

[stoivo]

My bad, did'r restart sublime but only refreshed modules. My bad. Now it work perfectly. I added 2 commits to your branch. Lets contiune the review over there.

[stoivo]

Continutes in #1138