GNOME Bugzilla – Bug 664624
Showing only xx lines around changes
Last modified: 2017-12-13 18:58:02 UTC
It would be great if Meld would have option that it would display only XX lines around the changes. If we compare two very long files and changes are only at the beginning, middle and at the end of the files, user must scroll through entire file to see the changes (or use shortcut option, Go To Next Difference). Instead Meld could have possibility to show only 3 (configurable) surrounding lines around changes and one (maybe gray) line where it is written how many lines are skipped. Option would be placed in Meld Preferences Window in tab Editor: Show only __ lines of context Example with 3 surrounding lines: - 8<------ BEGGING OF FILE ------------ >8 -- Skipped 10 lines 11 line 3 12 line 2 13 line 1 14 CHANGE 1 15 line 1 16 line 2 17 line 3 Skipped 513 lines 530 line 3 531 line 2 532 line 1 533 CHANGE 2 534 line 1 535 line 2 536 line 3 Skipped 312 lines 848 line 3 849 line 2 850 line 1 851 CHANGE 3 852 line 1 853 line 2 854 line 3 Skipped 31 lines - 8< ------------- END OF FILE ------------ >8 -- Best regards Marko
I think this sounds reasonable, particularly for situations like pre-commit review. However, rather than the preferences UI, I'd just have a fixed context size (~5 lines) and there would be a "View -> Compress identical sections" toggle menu entry, with its state stored with our other settings.
*** Bug 686923 has been marked as a duplicate of this bug. ***
Hi Kai, I'm still interested in implementing this feature. I already looked a little bit around in the code. Honestly I don't know yet where exactly to step in. But I am ready to play a little bit with the code. The only thing that worries me is how to actually make parts of the text disappear. I suppose there is no built-in mechanism in source views, is it? At least I could not find anything. So the only thing that comes to my mind is messing around with the text manually. But that does not seem to be a good idea. It would be nice to hear your opinion (or the opinion of someone else) regarding these points. David
This is a bit of a brain dump on options for getting started as well as some of the challenges involved in doing this properly. My initial impression is that to do this *really well* will be a very significant quantity of work, but we might be able to get something workable more easily. * I think the "best" way to think of this is that we want editor code folding based on the space around diff chunks, since that's essentially what we're asking for here. However, GtkSourceView doesn't have any built-in support for code folding. There's a recent-ish discussion about someone looking at it (https://mail.gnome.org/archives/gnome-devtools/2014-August/msg00000.html) but no conclusions, only ideas. Someone does address your question of how to make text disappear, which is to use an invisible GtkTextTag to tagged collapsed text. * Regardless of which approach we take, I don't see how we do real-time updating of diff chunks when we're in this mode. If the chunk list changes, the folds will change and that will be incredibly confusing to the user, so I think we need to disable that while keeping the inline highlighting updater. This isn't ideal, but anything else will be too much work IMO. If we're punting on real-time updating and code folding is too hard, then the implementation we're left with looks like: * Run the diff once after loading to get your diff points, then disable it if this option is on; * As a one-time-only operation, go through all of the diff chunks that we've identified, and for each of them find a spot X lines before the start and X lines after the end, and then collapse the resulting list of intervals; * Do some interval-subtraction style math on the list to get the list of boring bits we don't care about; and then * Create an invisible text tag (should probably also be uneditable), and tag each interval in the boring list Anyway, I'm extremely happy to help out with questions for this if you're keen. I think that the approach I've suggested is probably a bit of work, but not insanely so. Until GtkSourceView has code folding (or there's an implementation for GtkSourceView from elsewhere that we could reuse) I don't think it's worth looking at anything more complicated.
Actually I wouldn't like to put work in a not-so-nice solution. As you said, we essentially want code folding. So maybe the best would be to get in touch with GtkSourceView developers and try to implement code folding support. And honestly I would like to do it, but don't have the time at the moment. So I guess I have to leave this issue for now. Maybe another day. :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/36.