Hi,
I have created a few commands that are analogous to the Subversion commands which diff against a revision, but instead of generating a diff output, the result is sent to FileMerge for viewing, which IMHO is a whole lot easier to read.
The commands look like this:
-------------
require_cmd "${TM_SVN:=svn}" "If you have installed svn, then you need to either update your <tt>PATH</tt> or set the <tt>TM_SVN</tt> shell variable (e.g. in Preferences / Advanced)"
require_cmd opendiff "You must install the Apple developer tools to run FileMerge."
"$TM_BUNDLE_SUPPORT/bin/filemerge.sh" BASE "$TM_FILEPATH"
-------------
filemerge.sh looks like this:
-------------
#!/bin/sh # # $1 = svn revision # $2 = full path to file ($TM_FILEPATH)
# First see if the file is under svn control FILE=`basename "$2"` INFO_LINES=`svn info 2>&1 > /dev/null | wc -l`
if [ $INFO_LINES -eq 2 ]; then echo "The current file is not under subversion control" exit 206 fi
SIZE=`svn diff -r $1 "$2" | wc -m`
if [ $SIZE -eq 0 ]; then echo "No difference" exit 206 fi
INODE=`stat -f "%i" "$2"` TMPPATH="/tmp/tm-opendiff-$INODE.tmp" svn cat -r $1 "$2" > "$TMPPATH" opendiff "$TMPPATH" "$2"
-----------
To create a command for a different revision, change BASE in the command to something else (e.g. HEAD or PREV).
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
I have created a few commands that are analogous to the Subversion commands which diff against a revision, but instead of generating a diff output, the result is sent to FileMerge for viewing, which IMHO is a whole lot easier to read.
Could you possible release the actual bundle or bundle items? So us lazy people don't each have to redo all this stuff.
If this stuff really works well, let's just add it to the official TextMate bundles.
Thanks much much!
thomas Aylott—subtleGradient—oblivious@subtleGradient.com
I have created a few commands that are analogous to the Subversion commands which diff against a revision, but instead of generating a diff output, the result is sent to FileMerge for viewing, which IMHO is a whole lot easier to read.
Could you possible release the actual bundle or bundle items?
Sure, should I just post them to the list?
If this stuff really works well, let's just add it to the official TextMate bundles.
I didn't want to suggest that myself, but it makes sense. Ideally I think the way to go would be to integrate it with the existing Subversion bundle and check an environment variable (created by the user) to determine whether to use diff or FileMerge.
Now that I mention that, I'll make that change and post the modified Subversion bundle.
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
I didn't want to suggest that myself, but it makes sense. Ideally I think the way to go would be to integrate it with the existing Subversion bundle and check an environment variable (created by the user) to determine whether to use diff or FileMerge.
Actually, I was thinking of them as more options in the list. I have good use for both and I'd want to choose each time.
Ideally, you'd publish the files online somewhere and post the link to it here.
thomas Aylott—subtleGradient—oblivious@subtleGradient.com
On Apr 20, 2006, at 8:58 PM, thomas Aylott wrote:
I didn't want to suggest that myself, but it makes sense. Ideally I think the way to go would be to integrate it with the existing Subversion bundle and check an environment variable (created by the user) to determine whether to use diff or FileMerge.
Actually, I was thinking of them as more options in the list. I have good use for both and I'd want to choose each time.
There are likely to be additional diff utilities in the future, so that might not scale. I think the environment variable is a better overall solution. (I'd also prefer not to clutter the list with duplicate diff entries if we can avoid it. It's already pretty big, even though it's still missing a number of commands.)
However, at least for now, the diff commands could perhaps check to see whether a particular modifier key is held down and do the opposite of the environment variable setting.
Chris
If write a repeat loop (Python) everything indents properly. Then I want to surround the repeat loop with an if statement. How do I fix the indentation after that so the repeat loop is properly indented?
On Apr 21, 2006, at 10:35 AM, Geoff Canyon wrote:
If write a repeat loop (Python) everything indents properly. Then I want to surround the repeat loop with an if statement. How do I fix the indentation after that so the repeat loop is properly indented?
Select the "block" after the if statement and hit option-tab to indent it.
-- Brian Lalor / blalor@bravo5.org Stewardess: We know you have your choice of bankrupt carriers and we appreciate you choosing us.
On Apr 21, 2006, at 7:38 AM, Brian Lalor wrote:
On Apr 21, 2006, at 10:35 AM, Geoff Canyon wrote:
If write a repeat loop (Python) everything indents properly. Then I want to surround the repeat loop with an if statement. How do I fix the indentation after that so the repeat loop is properly indented?
Select the "block" after the if statement and hit option-tab to indent it.
That certainly works. Is there a way to just get TextMate to re- examine the text as if I were typing it from scratch, and thus indent it all appropriately without me having to figure out where changes are needed?
thx
gc
On 23/4/2006, at 4:42, Geoff Canyon wrote:
If write a repeat loop (Python) everything indents properly. Then I want to surround the repeat loop with an if statement. How do I fix the indentation after that so the repeat loop is properly indented?
Select the "block" after the if statement and hit option-tab to indent it.
That certainly works. Is there a way to just get TextMate to re- examine the text as if I were typing it from scratch, and thus indent it all appropriately without me having to figure out where changes are needed?
When should it do that? At all times? And enforcing the estimated indent for all lines in your document?
There is no such “feature”.
If however you often wrap code in an if loop, you could create a snippet which wraps the selection and adjusts the indent. There is a begin … rescue … end snippet in the Ruby bundle which does that -- select text, press ctrl-shift W, and it will “wrap” the selection in begin/rescue/end when the wrapped text given an extra indent.
On Apr 23, 2006, at 1:53 AM, Allan Odgaard wrote:
On 23/4/2006, at 4:42, Geoff Canyon wrote:
If write a repeat loop (Python) everything indents properly. Then I want to surround the repeat loop with an if statement. How do I fix the indentation after that so the repeat loop is properly indented?
Select the "block" after the if statement and hit option-tab to indent it.
That certainly works. Is there a way to just get TextMate to re- examine the text as if I were typing it from scratch, and thus indent it all appropriately without me having to figure out where changes are needed?
When should it do that? At all times? And enforcing the estimated indent for all lines in your document?
I would think when pasting, or on command.
There is no such “feature”.
If however you often wrap code in an if loop, you could create a snippet which wraps the selection and adjusts the indent. There is a begin … rescue … end snippet in the Ruby bundle which does that -- select text, press ctrl-shift W, and it will “wrap” the selection in begin/rescue/end when the wrapped text given an extra indent.
I see I have it backwards in the example I gave above. I actually ran into this when pasting some code into a pre-existing script. So the above wouldn't help in that instance. I'll look at it to see if there's a way I can adapt it.
Thanks!
gc
On 23/04/2006, at 10:53, Allan Odgaard wrote:
On 23/4/2006, at 4:42, Geoff Canyon wrote:
That certainly works. Is there a way to just get TextMate to re- examine the text as if I were typing it from scratch, and thus indent it all appropriately without me having to figure out where changes are needed?
When should it do that? At all times? And enforcing the estimated indent for all lines in your document? There is no such “feature”.
Visual Studio for one, does something of this kind :-p. When set at its default, it was quite annoying though, as it didn't fit my code style. Fortunately it's ridiculously configurable... some middle route would probably be prefered.
In fact, VS doesn't reident based on openers, but rather on closers. So when inserting a } it examines the preceding block. For Python I guess one would have to look forward to the next change of indent instead.. messy.
This reminds me, I do miss one thing in TM (also from VS): When you paste, TM reindents, which is fine. I'd like it to count as an action on the undo stack, so I can cancel the indentation (only), if I don't want or need it.
-- Sune.
On 24 Apr 2006, at 9:48, Sune Foldager wrote:
This reminds me, I do miss one thing in TM (also from VS): When you paste, TM reindents, which is fine. I'd like it to count as an action on the undo stack, so I can cancel the indentation (only), if I don't want or need it.
I hadn't realised it until now, but this single feature would let me start using the reindent-on-paste feature, which gets it "wrong" (based on my coding style only - nothing to do with TM being "at fault"!) just enough times to make it unusable for me. A quick "undo" to correct those ones would be brilliant.
/me hopes this is an easy add!
-J
On 24/4/2006, at 10:54, Jonathan Barrett wrote:
On 24 Apr 2006, at 9:48, Sune Foldager wrote:
This reminds me, I do miss one thing in TM (also from VS): When you paste, TM reindents, which is fine. I'd like it to count as an action on the undo stack, so I can cancel the indentation (only), if I don't want or need it.
I hadn't realised it until now, but this single feature would let me start using the reindent-on-paste feature, which gets it "wrong" (based on my coding style only - nothing to do with TM being "at fault"!) just enough times to make it unusable for me. A quick "undo" to correct those ones would be brilliant.
It is possible to paste without re-indenting using ctrl-cmd V.
I generally know upfront when TM will get it wrong (as I coded the bloody thing), but otherwise it would be: cmd Z, ctrl-cmd V when it gets it wrong. Not one keystroke (cmd Z alone) but two -- OTOH I personally would hate that undo’ing a paste would be a two-step operation (yes, options, damn options).
On Apr 21, 2006, at 10:17 AM, Chris Thomas wrote:
I didn't want to suggest that myself, but it makes sense. Ideally I think the way to go would be to integrate it with the existing Subversion bundle and check an environment variable (created by the user) to determine whether to use diff or FileMerge.
Actually, I was thinking of them as more options in the list. I have good use for both and I'd want to choose each time.
There are likely to be additional diff utilities in the future, so that might not scale. I think the environment variable is a better overall solution. (I'd also prefer not to clutter the list with duplicate diff entries if we can avoid it. It's already pretty big, even though it's still missing a number of commands.)
However, at least for now, the diff commands could perhaps check to see whether a particular modifier key is held down and do the opposite of the environment variable setting.
Currently, you can activate a command by 1) selecting it from the menu, 2) the gear menu, 3) a shortcut key, 4) a shortcut key list or 5) a tab selector.
I don't think the solution for scaling is to hide commands behind a preference setting or a second hidden shortcut.
I think the solution is the bundle editor. To be able to enable or disable the commands that you want or don't through a gui in the application. And the shortcut key list, if there are too many commands with the same activation method, choose you one you want.
I agree that we shouldn't clutter up the shortcut key lists, but for activating similar commands, that's the only current standard.
Are there currently any commands that are only available once you set an environment variable? I'd like to use them if there are. How would I find out about them?
I know there are a few commands that require you to set up your password or some other random environment variable to be able to run. But I've never heard of any that aren't even in the list until you set one, or any that change their behavior if you hold down keys while it's running or about to run.
For the sake of UI design, let's stick with the existing 5 activation methods until Allan gives us more.
It's difficult to balance discoverability, customization and allow for seamless scaling.
thomas Aylott—subtleGradient—oblivious@subtleGradient.com
On Apr 21, 2006, at 10:53 AM, thomas Aylott wrote:
Are there currently any commands that are only available once you set an environment variable? I'd like to use them if there are. How would I find out about them?
No one is suggesting separate commands for FileMerge that magically appear when you set an environment variable.
My suggestion was to use a standard Mac idiom (modifier key) for switching between alternative functionality, since you indicated that you'd sometimes want to use FileMerge for diff and sometimes standard svn diff. (I fully stipulate your point about discoverability. I know this is not discoverable, although it would be documented in the help file.) On second thought, though, it would probably end up triggering some other command, so never mind.
I don't think my concern about menu length is an invalid one. You're proposing adding five new Diff commands, assuming you replicate each of the existing commands, to what is already one of the longest command menus in TextMate.
When Allan provides a UI for grouping and enabling subsets of bundle commands, a separate set of commands will be great. Meanwhile, I'm not sure it's a good idea.
Chris
On 21 Apr 2006, at 17:16, Chris Thomas wrote:
On Apr 21, 2006, at 10:53 AM, thomas Aylott wrote:
Are there currently any commands that are only available once you set an environment variable? I'd like to use them if there are. How would I find out about them?
No one is suggesting separate commands for FileMerge that magically appear when you set an environment variable.
My suggestion was to use a standard Mac idiom (modifier key) for switching between alternative functionality, since you indicated that you'd sometimes want to use FileMerge for diff and sometimes standard svn diff. (I fully stipulate your point about discoverability. I know this is not discoverable, although it would be documented in the help file.) On second thought, though, it would probably end up triggering some other command, so never mind.
I don't think my concern about menu length is an invalid one. You're proposing adding five new Diff commands, assuming you replicate each of the existing commands, to what is already one of the longest command menus in TextMate.
When Allan provides a UI for grouping and enabling subsets of bundle commands, a separate set of commands will be great. Meanwhile, I'm not sure it's a good idea.
It would also be useful to set the order - in the subversion bundle when I do a diff, 99.99% of the time I want to diff with BASE so I would like to do control A d rather than control A d down down. Similarly I would find it better if revert were before resolve and status before show all modifications. Minor quibbles on an excellent bundle.
Dave.
Chris
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
On 21/4/2006, at 18:50, Dave Baldwin wrote:
On 21 Apr 2006, at 17:16, Chris Thomas wrote:
[...] I don't think my concern about menu length is an invalid one. You're proposing adding five new Diff commands, assuming you replicate each of the existing commands, to what is already one of the longest command menus in TextMate.
Yes, I agree. I do not want these in the Subversion bundle as other than either “hidden” behind the option key, or as environment variable toggled.
Keeping them in its own bundle for now I think is best, and then not use the ctrl-shift A key, because that ruins the ‘type to select’ feature of the menu system. So probably use ctrl-shift-cmd A.
When Allan provides a UI for grouping and enabling subsets of bundle commands, a separate set of commands will be great. Meanwhile, I'm not sure it's a good idea.
+1 to both :)
[...] It would also be useful to set the order - in the subversion bundle when I do a diff, 99.99% of the time I want to diff with BASE so I would like to do control A d rather than control A d down down.
You can re-order the items in the bundle editor. But ‘type to select’ works a little flaky when the items are not alphabetized. I think the system picks the first match as if the items where actually alphabetized, so the actual ordering has no influence on whatgets picked.
On 22/04/2006, at 9:09, Allan Odgaard wrote:
Yes, I agree. I do not want these in the Subversion bundle as other than either “hidden” behind the option key, or as environment variable toggled. Keeping them in its own bundle for now I think is best, and then not use the ctrl-shift A key, because that ruins the ‘type to select’ feature of the menu system. So probably use ctrl-shift-cmd A.
[Not addressed to anyone in particular:]
In the long run, I think it could be really useful with multikey shortcuts... given the number of bundles and the number of commands one wants available at all times. It would be easier to set up some sort of hierachy that way, and easier to avoid clashes. I'm not saying this should be used all the time, but then the primary items could carry normal hotkeys, and all the not so often used ones could have the secondaries.
This is not a feature suggestions as such; I know it's been up and is somewhere on a list of things to consider. Just making a point, seeing how every now and then the problem of 'what hotkey should we use' comes up.
-- Sune.
On Apr 23, 2006, at 7:37 PM, Sune Foldager wrote:
[Not addressed to anyone in particular:]
In the long run, I think it could be really useful with multikey shortcuts... given the number of bundles and the number of commands one wants available at all times. It would be easier to set up some sort of hierachy that way, and easier to avoid clashes. I'm not saying this should be used all the time, but then the primary items could carry normal hotkeys, and all the not so often used ones could have the secondaries.
This is not a feature suggestions as such; I know it's been up and is somewhere on a list of things to consider. Just making a point, seeing how every now and then the problem of 'what hotkey should we use' comes up.
Excellent point.
I have wished for multikey shortcuts for a while.
thomas Aylott—subtleGradient—oblivious@subtleGradient.com
On Apr 21, 2006, at 12:16 PM, Chris Thomas wrote:
I don't think my concern about menu length is an invalid one. You're proposing adding five new Diff commands, assuming you replicate each of the existing commands, to what is already one of the longest command menus in TextMate.
When Allan provides a UI for grouping and enabling subsets of bundle commands, a separate set of commands will be great. Meanwhile, I'm not sure it's a good idea.
You're right. We definitely have a scaling problem here.
Maybe in the mean time we should just have another shortcut for the filemerge versions of these. What do you think about ctrl-shift-opt-a ? That keeps the standard idea of what the option key is for.
--- I'm not sure what the best long term solution is to this. Logically, they should all be grouped together, but in separate sub groups or something. But that begs the problem of how to lay that out properly in the UI. I don't think the cocoa menu API is good enough to handle much complexity.
I'd really like to have the icons in the list and maybe add some indenting or grouping or something. The current cocoa menu stuff breaks select-as-you-type when you group stuff.
thomas Aylott—subtleGradient—oblivious@subtleGradient.com
Maybe in the mean time we should just have another shortcut for the filemerge versions of these. What do you think about ctrl-shift-opt-a ? That keeps the standard idea of what the option key is for.
Seems like a good idea, I'll do that in the next release.
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
Hi,
The first revision of the FileMerge bundle is available here:
http://www.aparajitaworld.com/site/private/FileMerge.tmbundle.zip
This bundle adds the following actions which are assigned to ^A:
FileMerge With Working Copy (BASE) FileMerge With Latest Revision (HEAD) FileMerge With Previous Revision (PREV) FileMerge With Revision... FileMerge Revisions...
These are analogous to the same commands in the Subversion bundle, but the output is sent to the FileMerge application (part of the Apple developer tools).
Enjoy!
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
On Apr 20, 2006, at 2:46 PM, Aparajita Fishman wrote:
INODE=`stat -f "%i" "$2"` TMPPATH="/tmp/tm-opendiff-$INODE.tmp" svn cat -r $1 "$2" > "$TMPPATH" opendiff "$TMPPATH" "$2"
Why not reuse the existing SVN diff code, using --diff-cmd, rather than duplicating all of the command infrastructure?
See http://www.wsanchez.net/blog/2005/08/filemerge_and_subversion.html.
Chris
INODE=`stat -f "%i" "$2"` TMPPATH="/tmp/tm-opendiff-$INODE.tmp" svn cat -r $1 "$2" > "$TMPPATH" opendiff "$TMPPATH" "$2"
FYI that's the old code I posted directly the other day, the latest version is different.
Why not reuse the existing SVN diff code, using --diff-cmd, rather than duplicating all of the command infrastructure?
1. I decided to make it into a separate, self-contained bundle. 2. Using --diff-cmd I would have had to write something like what you did, not knowing about it until now. 3. The SVN diff code was not _that_ complex to rewrite...
Regards,
Aparajita www.aparajitaworld.com
"If you dare to fail, you are bound to succeed." - Sri Chinmoy | www.srichinmoylibrary.com
On Apr 21, 2006, at 12:37 PM, Aparajita Fishman wrote:
Why not reuse the existing SVN diff code, using --diff-cmd, rather than duplicating all of the command infrastructure?
- I decided to make it into a separate, self-contained bundle.
- Using --diff-cmd I would have had to write something like what
you did, not knowing about it until now. 3. The SVN diff code was not _that_ complex to rewrite...
Well, there's also the issue of 'let's have the same bugs instead of different ones'. But I think putting the FileMerge commands in a separate bundle is a good solution for now.
No worries, Chris
-
Allan Odgaard -
Aparajita Fishman -
Brian Lalor -
Chris Thomas -
Dave Baldwin -
Geoff Canyon -
Jonathan Barrett -
Sune Foldager -
thomas Aylott