I have a follow-up to Aparajita's recent thread about adding FileMerge support to TextMate. I really like the idea, but as Chris pointed out, it shouldn't be necessary to clone the Subversion bundle or add special environment variables to TextMate. That's because Subversion isn't hard-coded to use diff; it can run any utility you want, as long as its arguments are diff-compatible. All you need to do is add a diff-cmd setting to ~/.subversion/config.
The problem, though, is that TextMate is hard-coded for diff. If you look at the svn_diff.rb file in the Subversion bundle, it forces svn to run diff instead of the user's diff-cmd. I think the best solution, then, is to change this file so that it's not hard-coded. Not only would this add support for FileMerge [1], but it would add support for any other diff utility, as well.
With that goal in mind, I've modified svn_diff.rb and posted my changes here: http://vocaro.com/trevor/files/svn_diff.rb
To try it out, simply replace your existing svn_diff.rb with this one. You'll then be able to specify a custom diff utility by setting the diff-cmd variable in ~/.subversion/config [2]. The next time you run a Subversion diff command, TextMate will automatically run your preferred diff utility. If you comment out the diff-cmd line (or delete the config file entirely), TextMate will go back to using the standard diff utility as before.
The only functional change here is that if you specify a custom diff- cmd and a file has no changes, you'll see no output when doing a diff on it, not even a tooltip [3]. The problem here is that with the regular diff, no output means no changes, but with custom (graphical) diff utilities, usually nothing is printed to stdout, even when there are changes. So, the command can't simply look at stdout and know whether changes were detected or not.
With that caveat, I hope some of you can try this out and let me know what you think. I'm hoping that with the proper vetting it can be checked into the repo. After all, it's a pretty low-impact change. No new bundles, no new commands, just different behavior when specifying a custom diff-cmd. (If none is specified, TextMate works exactly as it did before.)
Trevor
[1] Unfortunately, opendiff (FileMerge's command-line launcher) is not diff compatible. You'll need a wrapper script like this one: http://vocaro.com/trevor/files/filemerge (It's buggy, though. Although it works great for diffs against BASE, whenever the network is involved, such as diffs with HEAD or PREV, it sometimes works, sometimes doesn't. Can anyone help?) [2] I've posted an example config file here: http://vocaro.com/trevor/ files/config [3] When no custom diff-cmd is specified, you'll get a tooltip that says "No differences found."
On 28/4/2006, at 3:02, Trevor Harmon wrote:
[...] The problem, though, is that TextMate is hard-coded for diff [...]
That’s intentional, since some user had his svn diff set to something generating tty coloring of the diff output, useful in Terminal, but not TextMate.
I guess we could remove the hardcoded use of diff and simply instruct that user to only setup an alternative diff for interactive shells.
On Apr 27, 2006, at 10:35 PM, Allan Odgaard wrote:
On 28/4/2006, at 3:02, Trevor Harmon wrote:
[...] The problem, though, is that TextMate is hard-coded for diff [...]
That’s intentional, since some user had his svn diff set to something generating tty coloring of the diff output, useful in Terminal, but not TextMate.
I guess we could remove the hardcoded use of diff and simply instruct that user to only setup an alternative diff for interactive shells.
Yes, judging by the recent thread, I think there are more users who want to be able to change the diff command than there are those who need it hard-coded.
Although perhaps svn_diff.rb could be extended (yes, even more) to make everyone happy. For instance, it could check whether a TextMate environment variable, say TM_SVN_DIFF_CMD, is set. If so, the bundle would use this variable for the diff cmd; otherwise, it would default to the global Subversion preference, the way my modified version does now.
Trevor
On Apr 27, 2006, at 10:35 PM, Allan Odgaard wrote:
[...] The problem, though, is that TextMate is hard-coded for diff [...]
That’s intentional, since some user had his svn diff set to something generating tty coloring of the diff output, useful in Terminal, but not TextMate.
Okay, I think I've come up with a solution that will make everyone happy. My version of svn_diff now works like this:
If a custom diff is specified in ~/.subversion/config, and the TM_SVN_DIFF_CMD variable is not set, TextMate will use the custom diff (and assume it's a GUI app). Otherwise, if the TM_SVN_DIFF_CMD variable is set, TextMate will use that instead (and assume it's a console app). And if not, it will force svn to use plain old diff.
So, all the cases are handled. The guy who needed to override his custom Subversion diff command for TextMate can do so; those who simply want TextMate to use their graphical diff command (specified in Subversion's config file) will see that happen automatically. And as before, those who haven't specified a custom command won't see any difference in the way TextMate does diffs.
I'd like to submit the patch to the repo, but I don't have commit rights. Can someone take a look at this and approve it for me?
Trevor
Hmm, the mail server chewed up my post for some reason. Re-sending...
On Apr 27, 2006, at 10:35 PM, Allan Odgaard wrote:
[...] The problem, though, is that TextMate is hard-coded for diff [...]
That’s intentional, since some user had his svn diff set to something generating tty coloring of the diff output, useful in Terminal, but not TextMate.
Okay, I think I've come up with a solution that will make everyone happy. My version of svn_diff now works like this:
If a custom diff is specified in ~/.subversion/config, and the TM_SVN_DIFF_CMD variable is not set, TextMate will use the custom diff (and assume it's a GUI app). Otherwise, if the TM_SVN_DIFF_CMD variable is set, TextMate will use that instead (and assume it's a console app). And if not, it will force svn to use plain old diff.
So, all the cases are handled. The guy who needed to override his custom Subversion diff command for TextMate can do so; those who simply want TextMate to use their graphical diff command (specified in Subversion's config file) will see that happen automatically. And as before, those who haven't specified a custom command won't see any difference in the way TextMate does diffs.
I'd like to submit the patch to the repo, but I don't have commit rights. Can someone take a look at this and approve it for me?
Trevor
On Apr 27, 2006, at 10:35 PM, Allan Odgaard wrote:
[...] The problem, though, is that TextMate is hard-coded for diff [...]
That’s intentional, since some user had his svn diff set to something generating tty coloring of the diff output, useful in Terminal, but not TextMate.
Okay, I think I've come up with a solution that will make everyone happy. My version of svn_diff now works like this:
If a custom diff is specified in ~/.subversion/config, and the TM_SVN_DIFF_CMD variable is not set, TextMate will use the custom diff (and assume it's a GUI app). Otherwise, if the TM_SVN_DIFF_CMD variable is set, TextMate will use that instead (and assume it's a console app). And if not, it will force svn to use plain old diff.
So, all the cases are handled. The guy who needed to override his custom Subversion diff command for TextMate can do so; those who simply want TextMate to use their graphical diff command (specified in Subversion's config file) will see that happen automatically. And as before, those who haven't specified a custom command won't see any difference in the way TextMate does diffs.
I'd like to submit the patch to the repo, but I don't have commit rights. Can someone take a look at this and approve it for me?
Trevor
P.S. You may have noticed that my last two posts to this list (which were identical to the post above; I was trying to resend) were corrupted. I don't know what's going on. For some reason, the mail server has recently decided to chew up my mail on occasion. I assume it has something to do with my digital signature, but I've been using the same certificate ever since I started on this list and didn't have problems until recently. Does anyone know if there have been changes to this list server?
-
Allan Odgaard -
Trevor Harmon