Compare locks up Sublime 4?

[LorenAmelang]

I have /.config/sublime-text/Installed Packages/Compare Side-By-Side.sublime-package installed in Sublime 4. This has "just worked" in the past, and I never studied it much. Today any use of it locks up the Sublime interface forever, or at least several minutes, with a constant ~15% CPU load. Even with tiny files. It says it was updated today ???

I see /.config/sublime-text/Log, but it is empty and from what I see on the web the log files are only written after Sublime closes properly - which mine doesn't. Could that be true?

I also have /.config/sublime-text/Installed Packages/Origami.sublime-package installed, and it can actually compare the same files, but interleaved instead of side-by-side, which doesn't work for today's project. And once it is active, there seems no way to close its display pane short of quitting Sublime. Probably unrelated.

Is there some way to get more info?

[LorenAmelang]

Forgot to mention - the "Comparison results open in a new window" does not happen, the screen does not change at all when I try to trigger a compare.

This is on Arch Linux with Cinnamon, if that might matter.

[kaste]

The last release is from March 3. So you should have received no update today unless you did not restart Sublime within that period. "Origami" can't compare files as it is just a window/pane manager. This plugin could maybe hang for long lines (and very big files of course) as it relies on a python implementation to do the diff. I can imagine being catastrophic for long lines but I never tested it.

[LorenAmelang]

Tried some smaller files, worked for 1.7MB. A 13MB pair with only short lines (directory listings) locked up for 40+ minutes, with the system use shown in the

screenshot. No change from beginning to end... Have to minimize and remax Sublime for it to notice it is unresponsive.

Also... I seem to remember there being some highlight of changed lines in addition to the very dimly changed background behind the changed text. Am I imagining that? Spotting that background in a screenfull of text is difficult for my lousy vision! Can I change the visibility?

I made "one intraline modification". Why does it always say one line added, one deleted?

[kaste]

This tool is built for small files as I said as it is implemented in Python only -- 13 MB is not big but huge, source code files seldomly are more than 100kB. For huge files we would need to call out to a c/rust library.

The colors are defined by your color scheme as described here: https://github.com/kaste/Compare-Side-By-Side/releases/tag/v1.22.0 An example config can be found here: https://github.com/kaste/Compare-Side-By-Side/issues/4#issuecomment-1974877718

The stats are misleading. "x intra-line modifications" is just a guess as we don't count all +--pairs as intra-line modifications. The lines have to be similar enough. Maybe we should remove that stat.

[LorenAmelang]

Guess my age is showing, my ancient code files are way over 100kB... But I get that Python is not up to 13MB. Maybe you could peek at the file sizes as you begin, and warn us if the little python is likely to choke on them?

Thanks for the color info and especially the example! That's nice enough I didn't even hack on it.

I'd vote for "x intra-line modifications" counting lines that are recognizably similar in both files, and insert/delete for those that can't be mated to the other file. But exclusive - anything that fits in intra-line doesn't count in insert/delete. But I'd be happy with intra-line being removed if it is really too imprecise.

Again, thanks for making my life easier!

[DEVG2F]

It is choking a 16kb drupal files too in my case. Running Sublime 4180 (last current version) and v.1.23.0 of the compare package

[kaste]

There is a lot that can be improved here. Low hanging is to run https://github.com/kaste/Compare-Side-By-Side/blob/ad8df2ac3d9c1f26a09d436996853a6e97fe59dd/sbs_compare.py#L194C6-L194C19 on a worker thread. (As soon as we're off the UI thread, we can run a spinner; and, e.g. timeout the thread after x seconds.)

Now, I did not write this plugin, and I hate that and how calculation/data processing and side-effects are intertwined here. But ... in a second step, running a quick diff, and then after that running the intraline differ on each change, as opposed to run this in one block, is typically. Esp. as such intraline diffs then can run in chunks, prioritizing the visible viewport.

When we omit the python differ, we could also just run an executable like git diff which is pretty platform agnostic these days. However, that doesn't output intraline diffs. That comes at a startup cost of a few milliseconds. (Just to compute the line-by-line comparison.) After that startup cost, we likely can't compete with the diffing algorithm.