2009/7/20 Piotr Piastucki <[email protected]>: > On Mon, Jul 20, 2009 at 2:44 AM, Kai Willadsen <[email protected]> > wrote: >> >> One downside to your method is that chunk position is part of the >> cache. The most obvious issue with this is that any change that >> inserts or deletes lines causes lots of rediffing. For example, >> instead of typing a single character in your "meld filediff.py >> meldapp.py" example, just hit enter. > > Yes, that's why I am fully in favour of your approach :) > Just wanted to mention one rather minor (as the highlighting code should not > change often) disadvantage.
Well, I decided that your approach was well worth it too. :) I tested with a few different cases, and there are certainly benefits to doing as little work as possible. For example, in the case of tokenising the input text, just the splitting process can take a while on large change blocks... and my approach doesn't skip that. I've reworked your approach, and integrated my caching with it. I had to change the cache eviction, and while it has some flaws, I think it's pretty good without making the SequenceMatcher calls async or getting overcomplicated. Patches attached. Kai
0001-Avoid-retagging-whole-textbuffers-if-diff-chunks-hav.patch
Description: Binary data
0002-Cache-inline-diff-results-to-avoid-rediffing-blocks.patch
Description: Binary data
_______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
