Horizontal Scroll for JDiffPlugin
Submitted by Wednesday, 15 April, 2009 - 20:16
on
One thing that continually bugs me about graphical diff programs (not just JDiffPlugin, but every single one I've encountered) is that they don't scroll the viewport and move the caret to the column where the difference actually begins. As an example of a file where this is terribly useful, imagine an XML file where the diffs are spread out among hundreds of different elements, and most of the diffs begin at the end of a physical line that spans 200 - 1000 or more columns.
Word wrapping is really awful with XML, too, because most XML stuff doesn't wrap very well.
The solution, for me, was to hack JDiffPlugin to do what I want.
There are now two new plugin options under "General". Here are more thorough explanations of the behavior:
1. "Scroll horizontally to next/prev diff" -> When you activate the menu action `Plugins -> JDiff Plugin -> Go To {Next/Previous} Difference', the following occur:
(i.) The caret in both buffers is bound to the first character on the current physical line that differs between the files.
(ii.) The horizontal offset of the text area is set to align the caret with the left side of the text area. This, in effect, lets you see as much of your match as the text buffer will allow. There are two types of over/underflow: First, your match (the whole diff) can be so large that it still hangs off the viewport to the right. Second, your match can be small enough that the end of the line is hit, so the viewport doesn't actually align the caret all the way to the left.
2. "Select first word in next/prev diff" -> When you activate the menu action listed above, the first word of the diff is selected in both buffers. This is just a visual cue to further obviate the actual location of the diff. Ideally this feature would creep to select the entire diff, up to the end of the line (but not beyond).
This does have rather particular use cases:
1. Changes occurring frequently near the end of the line.
2. Many scattered changes at wildly different column positions.
3. Screens deprived of much horizontal width (such as laptops).
4. Enables very rapid deletion/modification of a batch of diffs that you already know how to fix, because the caret is placed right where you expect it to be for each diff.
I split my changes into a separate .patch file for each. This tarball does create a folder upon extraction so you won't get spew if you untar it without creating a folder
http://tiyukquellmalz.org/horiz_scroll_patch.tar.bz2
I also added a new API function to the core JEdit object TextArea in the hope that it will be useful. I needed to implement this method to solve my problem (1) above. Perhaps it can be extended to do left/center/right justification based on an enum value, but that's a bit out of the scope of my work for now.
Note: this patch will NOT work without also rebuilding jEdit from source and incorporating the modified TextArea.
Thanks,
Sean McNamara
Word wrapping is really awful with XML, too, because most XML stuff doesn't wrap very well.
The solution, for me, was to hack JDiffPlugin to do what I want.
There are now two new plugin options under "General". Here are more thorough explanations of the behavior:
1. "Scroll horizontally to next/prev diff" -> When you activate the menu action `Plugins -> JDiff Plugin -> Go To {Next/Previous} Difference', the following occur:
(i.) The caret in both buffers is bound to the first character on the current physical line that differs between the files.
(ii.) The horizontal offset of the text area is set to align the caret with the left side of the text area. This, in effect, lets you see as much of your match as the text buffer will allow. There are two types of over/underflow: First, your match (the whole diff) can be so large that it still hangs off the viewport to the right. Second, your match can be small enough that the end of the line is hit, so the viewport doesn't actually align the caret all the way to the left.
2. "Select first word in next/prev diff" -> When you activate the menu action listed above, the first word of the diff is selected in both buffers. This is just a visual cue to further obviate the actual location of the diff. Ideally this feature would creep to select the entire diff, up to the end of the line (but not beyond).
This does have rather particular use cases:
1. Changes occurring frequently near the end of the line.
2. Many scattered changes at wildly different column positions.
3. Screens deprived of much horizontal width (such as laptops).
4. Enables very rapid deletion/modification of a batch of diffs that you already know how to fix, because the caret is placed right where you expect it to be for each diff.
I split my changes into a separate .patch file for each. This tarball does create a folder upon extraction so you won't get spew if you untar it without creating a folder
http://tiyukquellmalz.org/horiz_scroll_patch.tar.bz2
I also added a new API function to the core JEdit object TextArea in the hope that it will be useful. I needed to implement this method to solve my problem (1) above. Perhaps it can be extended to do left/center/right justification based on an enum value, but that's a bit out of the scope of my work for now.
Note: this patch will NOT work without also rebuilding jEdit from source and incorporating the modified TextArea.
Thanks,
Sean McNamara