After the small features request, here is a big one ;) I'm sure we talked about it here, but I don't remember if this is planned or not.
Actually, I use TextMate for everything text-related except one thing: comparing two document(Diff). Unfortunately I need this feature a lot. For me, this is "The Last Big Thing" that TM misses.
The best solution I found so far is to have a command launching TextWrangler to compare the active one and one I have to choose(w/Cocoa Dialog). 1) The way to launch this is a bit clumsy. (Having to navigate thru an "open" dialog) 2) Having TextWrangler opened just for that sucks a bit. 3) Having to edit the files in TW really sucks. I miss all the TM goodness and It makes me feels I'm back in time. ;) (And worst of all, I use TM shortcuts all the time and wonder why my commands, snippets, etc. don't work 8-| ) 4) This doesn't work with remote files, or I have to open them in TW. Meaning changing the prefs of my SFTP client.
What I like in the "Compare two front documents" feature of TW: -The full screen is shared by the two docs with the Differences window under. -You can navigate easily thru the diffs. -Closing the Differences window brings the docs back where they were. -It exists. ;) You can even check differences of folders and batch files.
So, my question is: Do you plan to implement this in TM, Allan? If the answer is yes, any idea when we might expect this?
Meanwhile, does anybody have a better solution?
-- Thanks
I pretty much agree with this, with a modification. Firstly, I have no idea what TextWrangler is. At least I don't see it on my systems. Secondly, rather than implementing a complete diff handler, what's wrong with opening the FileMerge application that is part of the OS X dev kit? (/Developer/Applications/Utilities/FileMerge.app)
Ideally, you'd be able to supply both 'files' to the program and when it's saved it'd drop the changes into the TextMate buffer. I have no idea if this is possible or not with FileMerge, but it's a thought I wanted to throw out.
On Feb 17, 2005, at 10:43 AM, Fred B. wrote:
After the small features request, here is a big one ;) I'm sure we talked about it here, but I don't remember if this is planned or not.
Actually, I use TextMate for everything text-related except one thing: comparing two document(Diff). Unfortunately I need this feature a lot. For me, this is "The Last Big Thing" that TM misses.
The best solution I found so far is to have a command launching TextWrangler to compare the active one and one I have to choose(w/Cocoa Dialog).
- The way to launch this is a bit clumsy. (Having to navigate thru an
"open" dialog) 2) Having TextWrangler opened just for that sucks a bit. 3) Having to edit the files in TW really sucks. I miss all the TM goodness and It makes me feels I'm back in time. ;) (And worst of all, I use TM shortcuts all the time and wonder why my commands, snippets, etc. don't work 8-| ) 4) This doesn't work with remote files, or I have to open them in TW. Meaning changing the prefs of my SFTP client.
What I like in the "Compare two front documents" feature of TW: -The full screen is shared by the two docs with the Differences window under. -You can navigate easily thru the diffs. -Closing the Differences window brings the docs back where they were. -It exists. ;) You can even check differences of folders and batch files.
So, my question is: Do you plan to implement this in TM, Allan? If the answer is yes, any idea when we might expect this?
Meanwhile, does anybody have a better solution?
-- Thanks
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 17. feb 2005, at 19:44, Robert M.Zigweid wrote:
I pretty much agree with this, with a modification. Firstly, I have no idea what TextWrangler is.
That would be "BBEdit Lite", their free version. As bad as the full version ;-).
On 17 févr. 05, at 19:44, Robert M.Zigweid wrote:
I Secondly, rather than implementing a complete diff handler, what's wrong with opening the FileMerge application that is part of the OS X dev kit? (/Developer/Applications/Utilities/FileMerge.app)
I already tried to convince myself that I could use FileMerge... Filemerge's diff representation is cool, but it's almost impossible to do any edit there, as you have to make the edit in the 3rd "merge" panel and you can only save to one file (by merging to one of the file). I want to be able to edit both of them. FM looks like a never finished product, IMHO. So it's worst than using TW...
On 17 févr. 05, at 19:46, Torsten Becker wrote:
comparing files visually is possible, if you have beta 5 you can use this command: (its based on some of chris thomas' subversion commands)
Yeah, but do you see the difference between this solution and BBEdit/TW or even FileMerge's one? Even with links to the files as Eric Hsu proposed this would still not be as good as my actual solution. It's much more easier to see the differences and edit them in the "real" files, with only an highlight of the selected difference, not all the "diff" messages.
On 17 févr. 05, at 21:48, Sune Foldager wrote:
That would be "BBEdit Lite", their free version. As bad as the full version ;-).
We're all here cause we prefer paying for TM than using TW for free, but BB/TW still have some feature no other editor on mac has. Like.... a good diff feature? ;)
I maybe biased because I used BBEdit before TM, but comparing two docs easily is something I'm used to.
At 12:28 AM +0100 2/18/05, Fred B. wrote:
Yeah, but do you see the difference between this solution and BBEdit/TW or even FileMerge's one? Even with links to the files as Eric Hsu proposed this would still not be as good as my actual solution. It's much more easier to see the differences and edit them in the "real" files, with only an highlight of the selected difference, not all the "diff" messages.
I think this might be possible if Allan added a feature to txmt:// that allowed one to not only jump to a line and character, but also to select a range. And better yet, allow a URL to call a command. But this is probably a few versions down the road.
By the way, I do think BBEdit's diff is pretty good (I bought it a few versions back), possibly their best feature. I think that and Palettes are the main features distinguishing it from TM at the moment.
- Eric
On Thu, 17 Feb 2005 16:43 (+0100), Fred B. wrote:
After the small features request, here is a big one ;) I'm sure we talked about it here, but I don't remember if this is planned or not.
Actually, I use TextMate for everything text-related except one thing: comparing two document(Diff). Unfortunately I need this feature a lot. For me, this is "The Last Big Thing" that TM misses.
The best solution I found so far is to have a command launching TextWrangler to compare the active one and one I have to choose(w/Cocoa Dialog).
- The way to launch this is a bit clumsy. (Having to navigate thru an
"open" dialog) 2) Having TextWrangler opened just for that sucks a bit. 3) Having to edit the files in TW really sucks. I miss all the TM goodness and It makes me feels I'm back in time. ;) (And worst of all, I use TM shortcuts all the time and wonder why my commands, snippets, etc. don't work 8-| ) 4) This doesn't work with remote files, or I have to open them in TW. Meaning changing the prefs of my SFTP client.
What I like in the "Compare two front documents" feature of TW: -The full screen is shared by the two docs with the Differences window under. -You can navigate easily thru the diffs. -Closing the Differences window brings the docs back where they were. -It exists. ;) You can even check differences of folders and batch files.
So, my question is: Do you plan to implement this in TM, Allan? If the answer is yes, any idea when we might expect this?
Meanwhile, does anybody have a better solution?
-- Thanks
comparing files visually is possible, if you have beta 5 you can use this command: (its based on some of chris thomas' subversion commands)
TMPFILE=`mktemp /tmp/tm-svn.XXXXXX` || exit 1 mv "$TMPFILE" "$TMPFILE.diff" TMPFILE="$TMPFILE.diff"
ruby > "$TMPFILE" <<END puts %x{diff -u $TM_SELECTED_FILES} END
open -a TextMate "$TMPFILE" &
Save: Nothing Input: None Output: Discard
you can select 2 files in the project drawer and after executing this command a colored diff should pop up.
At 7:46 PM +0100 2/17/05, Torsten Becker wrote:
you can select 2 files in the project drawer and after executing this command a colored diff should pop up.
I bet someone enterprising, and with more time than me could:
1. ramp up Torsten's command to output hyperlinked diffs, so clicking on the diff jumps to the appropriate document and line;
2. (less obvious) use Applescript to move the two original windows side by side and put the diff output in a lower window.
- Eric
At 12:38 PM -0800 2/17/05, Eric Hsu wrote:
At 7:46 PM +0100 2/17/05, Torsten Becker wrote:
you can select 2 files in the project drawer and after executing this command a colored diff should pop up.
I bet someone enterprising, and with more time than me could:
- ramp up Torsten's command to output hyperlinked diffs, so
clicking on the diff jumps to the appropriate document and line;
- (less obvious) use Applescript to move the two original windows
side by side and put the diff output in a lower window.
Okay, I wasted a lot of time today doing #1 above. It now shows the changes in color inline with the unchanged parts of the document. Clicking on a line takes you to the newer version (or if it's a deletion) to the older version.
I had wanted to add cool links (like in the Subversion Log command) to show/hide the common parts and also allow switching which document was considered the newer one. As it is now, whichever one appears first in the TM project drawer is the 'older' one.
It's a start. I think it can become cooler with time.
The Bundle is at http://macromates.com/svn/Bundles/trunk/Diff.tmbundle/
- Eric
On 19 févr. 05, at 02:37, Eric Hsu wrote:
At 12:38 PM -0800 2/17/05, Eric Hsu wrote:
At 7:46 PM +0100 2/17/05, Torsten Becker wrote:
- ramp up Torsten's command to output hyperlinked diffs, so clicking
on the diff jumps to the appropriate document and line;
- (less obvious) use Applescript to move the two original windows
side by side and put the diff output in a lower window.
Okay, I wasted a lot of time today doing #1 above. It now shows the changes in color inline with the unchanged parts of the document. Clicking on a line takes you to the newer version (or if it's a deletion) to the older version.
I had wanted to add cool links (like in the Subversion Log command) to show/hide the common parts and also allow switching which document was considered the newer one. As it is now, whichever one appears first in the TM project drawer is the 'older' one.
It's a start. I think it can become cooler with time.
The command doesn't appear when I install it. I tried to remove the older Diff.bundle, but that didn't make the trick, maybe I'm missing something. I copy/pasted it but couldn't figure how to load the css files locally. No problem if I put them on a server. But I didn't took the time to figure it out, maybe I'm missing something again. Plus, external css files are loaded after the the html ouptut is completed, not that nice as it is slow.
(BTW, why is the html output much more slower than html preview? It can be 30 times slower on big files.)
Back to your command: There is some @@......@@ lines appearing in the output (offsetting the links). I was trying on two css files.
Then, I made some thinking/testing with your command. After spending a lot of time trying.. lot of things (in Ruby, Perl doesn't like me ;), I thought someone should already have made a diff to html script and after a lot of time again, I found one. It's called hdiff and you can find it here:http://www.ginini.com/software/hdiff/ . It's a Perl script that parses the diff -u output in html, putting the two docs side-by-side and colorizing "Line added, line removed and line changed. It offset the docs when there is line added or removed, too. That looks quite cool.
So, I thought I could try to link the line numbers to TM files, but: First, the hdiff's -n (put the line number in front of every line) option was broken (if I'm right an "$$" that should be "$" @ line 144.) Then I realized the line numbers where just the start of the ranges, not every lines :(
To add link to TM files is easy, but I don't know if it's even possible to output each line number, but if it's possible that could be a pretty nice solution.
I'll look more into it in the coming days, either with hdiff (But...Perl :( I might even try to rewrite everything in Ruby.), or with your script, Eric.
Any answers/idea are welcome.
Sorry to be longish.
On Feb 21, 2005, at 10:47, Fred B. wrote:
The command doesn't appear when I install it. I tried to remove the older Diff.bundle, but that didn't make the trick, maybe I'm missing something.
Does the bundle appear, but just not the command? If the bundle doesn't appear, quit TextMate and execute: defaults delete com.macromates.textmate OakBundleManagerDeletedBundles That should restore any default bundles that may have previously been deleted.
(BTW, why is the html output much more slower than html preview? It can be 30 times slower on big files.)
Because I reload the content each time there is new output from the command -- I'll improve that in the future.
On 21 févr. 05, at 13:37, Allan Odgaard wrote:
On Feb 21, 2005, at 10:47, Fred B. wrote:
The command doesn't appear when I install it. I tried to remove the older Diff.bundle, but that didn't make the trick, maybe I'm missing something.
Does the bundle appear, but just not the command? If the bundle doesn't appear, quit TextMate and execute: defaults delete com.macromates.textmate OakBundleManagerDeletedBundles That should restore any default bundles that may have previously been deleted.
Sorry, that was not really clear. The bundle doesn't appear but the syntax highlight does.
(BTW, why is the html output much more slower than html preview? It can be 30 times slower on big files.)
Because I reload the content each time there is new output from the command -- I'll improve that in the future.
Ok. Btw, I tried to set "dontFollowNewOutput" to false in the plist, but that didn't stop scrolling.
On Feb 21, 2005, at 14:12, Fred B. wrote:
The command doesn't appear when I install it. I tried to remove the older Diff.bundle, but that didn't make the trick, maybe I'm missing something.
Does the bundle appear, but just not the command? If the bundle doesn't appear, quit TextMate and execute: defaults delete com.macromates.textmate OakBundleManagerDeletedBundles That should restore any default bundles that may have previously been deleted.
Sorry, that was not really clear. The bundle doesn't appear but the syntax highlight does.
And you have “Show All” or “Show Commands” selected above the list, right?
Try to open Console.app, if TextMate fails to parse a bundle item, it should output an error for that item.
Btw, I tried to set "dontFollowNewOutput" to false in the plist, but that didn't stop scrolling.
You need to set it to true -- yeah, I ought to know better about not using double negations to enable features ;)
At 10:47 AM +0100 2/21/05, Fred B. wrote:
To add link to TM files is easy, but I don't know if it's even possible to output each line number, but if it's possible that could be a pretty nice solution.
You can figure out the line numbers from the 'changes only' diff if you keep a running count of the 'old' and 'new' line numbers, which you can infer from the chunks of text. Or you can use diff -u and have it all inline. Which I always prefer anyway.
I'll look more into it in the coming days, either with hdiff (But...Perl :( I might even try to rewrite everything in Ruby.), or with your script, Eric.
Good luck! Have a look at the subversion bundle for ideas on HTML output. The stuff Chris and Torsten are doing are quite cool. I'll let you know if I start work on this again.
- Eric
Okay, so I'm trying to hack out a little diff command. I've run into a couple of peculiar behaviors I don't understand. They all must have obvious answers...
1. In my setup, a command of
echo $TM_SELECTED_FILES | xargs diff -u
works but
diff -u $TM_SELECTED_FILES
does not. I get a "diff: file not found" error.
2. I wanted to emulate the BBEdit feature of popping up a list of all open windows, but I saw no TM_OPEN_WINDOWS variable equivalent. I tried using Applescript to
osascript -e 'tell app "TextMate.app" to return name of every window'
which worked great except for the lack of path information, and then I tried
osascript -e 'tell app "TextMate.app" to return path of every window'
which seemed like the right thing to do, but gave me a
34:38: execution error: TextMate got an error: NSCannotCreateScriptCommandError (10)
Any thoughts?
best, Eric
On Feb 18, 2005, at 20:18, Eric Hsu wrote:
- In my setup, a command of
echo $TM_SELECTED_FILES | xargs diff -u
works but
diff -u $TM_SELECTED_FILES
does not. I get a "diff: file not found" error.
I think the problem is that the shell passes the variable as a single argument to diff. So basically in #2 it calls: diff -u "'file1' 'file2'". I am however not entirely sure about this.
You can btw make #1 like this: xargs <<<$TM_SELECTED_FILES diff -u
osascript -e 'tell app "TextMate.app" to return path of every window'
which seemed like the right thing to do, but gave me a
34:38: execution error: TextMate got an error: NSCannotCreateScriptCommandError (10)
Any thoughts?
The window doesn't have a path attribute. You can do: osascript -e 'tell app "TextMate.app" to return name of every window'
But probably not very helpful. To get the path I think one is supposed to go through the document of each window, but TextMate is unlikely to support this (since I do not use NSDocument).
On 19. feb 2005, at 6:28, Allan Odgaard wrote:
On Feb 18, 2005, at 20:18, Eric Hsu wrote:
- In my setup, a command of
echo $TM_SELECTED_FILES | xargs diff -u
works but
diff -u $TM_SELECTED_FILES
does not. I get a "diff: file not found" error.
I think the problem is that the shell passes the variable as a single argument to diff. So basically in #2 it calls: diff -u "'file1' 'file2'". I am however not entirely sure about this.
Sounds odd. Even if I do stuff like A='"foo bar"' ls $A I get "foo not found, bar" not found. I don't think it passes it as a single argument.
On Feb 19, 2005, at 14:31, Sune Foldager wrote:
I think the problem is that the shell passes the variable as a single argument to diff. So basically in #2 it calls: diff -u "'file1' 'file2'". I am however not entirely sure about this.
Sounds odd. Even if I do stuff like A='"foo bar"' ls $A I get "foo not found, bar" not found. I don't think it passes it as a single argument.
Nah, seems the quotes are the problem:
% tst () { echo $1; } % foo="'this' 'is' 'a' 'test'" % tst $foo 'this'
On 19. feb 2005, at 14:41, Allan Odgaard wrote:
On Feb 19, 2005, at 14:31, Sune Foldager wrote:
Sounds odd. Even if I do stuff like A='"foo bar"' ls $A I get "foo not found, bar" not found. I don't think it passes it as a single argument.
Nah, seems the quotes are the problem: % tst () { echo $1; } % foo="'this' 'is' 'a' 'test'" % tst $foo 'this'
I don't get it; this is expected behaviour, no? At least I expected this ;-). It obviously splits foo. It would still split it if you had done "'this is a' test" or similar.
On 19. feb 2005, at 15:21, Allan Odgaard wrote:
On Feb 19, 2005, at 15:19, Sune Foldager wrote:
I don't get it; this is expected behaviour, no?
Did you read Eric's post? Do you know how we can solve this problem w/o using xargs?
Oh.. we can't. The quotes are taken as part of the name, since bash doesn't do any further processing on expanded variables. Thus, unless fed to an argument splitter like xargs, quotes strings in variables are not very useful. An alternative *could* be to use bash array env-vars. I don't know how you can manipulate those though :-p.
On 19. feb 2005, at 23:15, Sune Foldager wrote:
Oh.. we can't. The quotes are taken as part of the name, since bash doesn't do any further processing on expanded variables.
Actually, bash is quite inconsistent. I _does_ split up text in expanded variables as normal, but doesn't allow quoting or escaping :-(. So basically it's impossible to include a space in a variable that should not be an argument boundary. Nice :-/.
On Feb 19, 2005, at 23:19, Sune Foldager wrote:
Oh.. we can't. The quotes are taken as part of the name, since bash doesn't do any further processing on expanded variables.
Actually, bash is quite inconsistent. I _does_ split up text in expanded variables as normal
Indeed it is, cause something like this:
foo='this is a spaced variable' xargs <<<$foo -n1 echo
actually works fine, whereas one would think it should be:
xargs <<<"$foo" -n1 echo
Maybe there is something similar to “precedence” rules for bash? ;)
On Feb 19, 2005, at 23:15, Sune Foldager wrote:
I don't get it; this is expected behaviour, no?
Did you read Eric's post? Do you know how we can solve this problem w/o using xargs?
Oh.. we can't. The quotes are taken as part of the name, since bash doesn't do any further processing on expanded variables. Thus, unless fed to an argument splitter like xargs, quotes strings in variables are not very useful. An alternative *could* be to use bash array env-vars. I don't know how you can manipulate those though :-p.
Just found the “solution”, we can convert TM_SELECTED_FILES to an array using eval, example: eval FILES=($TM_SELECTED_FILES) for ((i=0; i < ${#FILES[@]}; i++)); do ls -l "${FILES[i]}" done
Or as required in the original example: eval FILES=($TM_SELECTED_FILES) diff -u "${FILES[0]}" "${FILES[1]}"
Though generally the xargs version is nicer, and also, it would work if the file names contained quotes, which the above doesn't take care of.
And should you want to use the above, you may want to set the input field separator (IFS) to just a space (by default it also contains tab and newline) -- not that I really expect anyone to find this useful, but at least it seems there is a solution which doesn't involve an argument splitter like xargs.
On Feb 17, 2005, at 16:43, Fred B. wrote:
Actually, I use TextMate for everything text-related except one thing: comparing two document(Diff). Unfortunately I need this feature a lot. For me, this is "The Last Big Thing" that TM misses.
[...] So, my question is: Do you plan to implement this in TM, Allan? If the answer is yes, any idea when we might expect this?
I must confess that I do not fully understand why a diff tool needs to be built into a text editor. Was it the missing ability to edit the merged file in File Merge that made this tool unusable?
At present time I have no plans of adding this feature mainly because a) I haven't fully understood the need to have it built in (i.e. a third party could write the tool if e.g. File Merge isn't sufficient) and b) there are many pending things that needs to built in (i.e. a third party cannot supply these things), so these have higher priority.
But I do see several people mention the diff thing, so it's not out of the question that I may see the advantages of having it built in, but then we're talking 1.3.
On Fri, 18 Feb 2005 15:35:15 +0100, Allan Odgaard allan@macromates.com wrote:
I must confess that I do not fully understand why a diff tool needs to be built into a text editor. Was it the missing ability to edit the merged file in File Merge that made this tool unusable?
I guess you would have to have used the BBEdit file differences tool to appreciate how useful it is. Many times, I find myself trying to adjudicate differences between two text files (say a weblog config file on my server with a new config file included in an updated of the blog software), etc. This is when I need to call on BBEdit. I haven't tried File Merge.
-- Kai.
On 18 févr. 05, at 15:35, Allan Odgaard wrote:
I must confess that I do not fully understand why a diff tool needs to be built into a text editor.
I must confess I don't fully understand how you can work without it ;)
And why in a text-editor? It's text and I want to edit it. I don't want to sound sarcastic, but it's as simple as that. It's a way to edit text I use really often. How could I do? Open the docs in another app, compare docs, note the line where I want to apply changes, switch back to the editor, find the line, make the change, re-compare, and again? And if I want to "save as" , I have to reopen them in TM after... Wow.
I can hardly see how this could be somewhere else that in a text editor, in fact.
Maybe I'm missing something: Don't you use diff at all? Don't you want to edit the docs you're comparing?
I'm sorry to even write this, but did you try TextWrangler's "compare two front docs"? And if you did, don't you see the advantages over other alternatives?
Was it the missing ability to edit the merged file in File Merge that made this tool unusable?
Yes. And in Filemerge, you can only apply edit to one file. Plus FileMerge is far from being polished: It doesn't remember window position, you have to reopen the 3rd panel each time. Scroll wheel just scroll horizontally, etc.
At present time I have no plans of adding this feature mainly because a) I haven't fully understood the need to have it built in (i.e. a third party could write the tool if e.g. File Merge isn't sufficient) and b) there are many pending things that needs to built in (i.e. a third party cannot supply these things), so these have higher priority.
The problem is the best tool I found to compare two docs in OS X is the free product of one of your direct competitor, the exact one I tried to escape by buying TM. You make me used to all the nice feature of TM, understand that I'm unhappy when I have to go back to another editor. ;) I would be ok to buy a good diff tool ( it doesn't exists, AFAIK) but it's editing capabilities will surely suck compared to TM, or even to TW, which is free. As you can see in the list, people who used BB/TW before really liked this feature.
But I do see several people mention the diff thing, so it's not out of the question that I may see the advantages of having it built in, but then we're talking 1.3.
Common' several people, stand up! ;) Seriously, I understand you have to make choices to avoid TM being bloated, but I really hope you'll consider this one. As I said, except for a better language/bundle integration, which I know you're working on, this is the last big thing missing in TM, for me. SFTP could be nice too, but 99% of the time a 3rd party SFTP client can do the job.
Thanks for your time.
-- Fred
At 5:33 PM +0100 2/18/05, Fred B. wrote:
But I do see several people mention the diff thing, so it's not out of the question that I may see the advantages of having it built in, but then we're talking 1.3.
Common' several people, stand up! ;)
As one who spoke in appreciation of BBEdit's diff, I think it should *not* be a priority for Allan. Sorry. :)
I personally prefer that he works on providing infrastructure that can support add-on work by procrastinators like the current bunch of bundle writers. I would rather he work on exposing some of the power that might lead to someone else writing a good version of the diff and that would be good for other stuff (like letting commands/urls select-highlight text; letting urls call commands, etc.).
I'm curious now how diff fits in your workflow. Are you constantly comparing to previous versions? I use diff maybe a couple times a week when I can't tell the difference between two similar files. If diff were the most important thing to me, I might have stayed with BB. Maybe you should install svn and use the svn bundle, which I might add looks great.
Chris Thomas writes:
BBEdit's diff implementation is about the least UI work you can do and still claim to have a diff feature.
I don't think that's completely fair. After all, Torsten's quick hack gives diff, but has less effect.
In BBEdit, you have two normal document windows placed side-by-side, and below them, you have this custom window... This window provides all of the diff logic (from a UI perspective). There isn't even unique graphics or interaction in the source windows, it just selects the differences using the normal selection mechanism.
With just a few TM callbacks exposed, we could duplicate this functionality via scripting.
I agree, this is what I meant by 'infrastructure' above. And the callbacks would be very helpful for other causes as well. For instance, if a command could output highlighted text (not sure what interface format, but let's pretend), then one could also quickly write a language-sensitive "highlight text out to the nearest braces" command.
A better implementation would provide a modern, polished version of FileMerge's view. That would almost certainly require Objective-C (or F-script) plugins if done by a third-party, though.
That would be really neat. FileMerge looks pretty great. It isn't too fun to edit with though.
best wishes, Eric
On Feb 18, 2005, at 10:26 AM, Eric Hsu wrote:
BBEdit's diff implementation is about the least UI work you can do and still claim to have a diff feature.
I don't think that's completely fair. After all, Torsten's quick hack gives diff, but has less effect.
You are correct, of course. I meant "merge feature"... And it's still not completely fair, the MPW script implementation was more precisely the least amount of work you could do and still have a merge feature.
Chris
On 18 févr. 05, at 19:26, Eric Hsu wrote:
As one who spoke in appreciation of BBEdit's diff, I think it should *not* be a priority for Allan. Sorry. :)
I never asked it to be in the next release, of course. An "it's on the bottom of the to-do list" would be a good start. ;)
I personally prefer that he works on providing infrastructure that can support add-on work by procrastinators like the current bunch of bundle writers. I would rather he work on exposing some of the power that might lead to someone else writing a good version of the diff and that would be good for other stuff (like letting commands/urls select-highlight text; letting urls call commands, etc.).
Sometimes, my english is not good enough to express exactly what I mean, sorry, but be sure i'd prefer to see "some of the power that might lead to someone else writing a good version of the diff and that would be good for other stuff " too. Change my request to "please, Allan, expose "some of the power, etc ". ;)
I'm curious now how diff fits in your workflow. Are you constantly comparing to previous versions? I use diff maybe a couple times a week when I can't tell the difference between two similar files. If diff were the most important thing to me, I might have stayed with BB. Maybe you should install svn and use the svn bundle, which I might add looks great.
I work on a lot of very different things (music, cd/dvd authoring, video, writings, xhtml, css, Rails, Ruby, Xcode, etc.), so I often need to check what I've done on a project lately. I already use svn and the svn bundle a lot, but : - Not everything I work on is on svn and the svn diff, even if svnX makes it much better, is still much less friendly than comparing two docs à la BBE/TW/FileMerge. - Sometimes, I have to compare a file to something else than one of its ancestors. An example: I work on a site that uses multiple stylesheets (the user can switch between them). And as I don't edit and test both of them at the same time, it's easier to check the one I'm working with the others to see what I've changed. I even dream of a way to compare more than 2 files, and maybe to be able to make edits in all of them at the same time. Ok, ok, I calm down.
Diff is not "the most important thing to me", but still... And NO, I won't go back to BBE! ;)
Chris Thomas writes:
BBEdit's diff implementation is about the least UI work you can do and still claim to have a diff feature. With just a few TM callbacks exposed, we could duplicate this functionality via scripting.
Yes, I think it could even be possible to recreate the compare command in BBE/TW with applescript. Maybe it's an applescript, in fact... That's why I took it as example, It seemed "simple enough". (I don't mean that implementing the necessary AS support in TM would be simple at all!)
A better implementation would provide a modern, polished version of FileMerge's view. That would almost certainly require Objective-C (or F-script) plugins if done by a third-party, though.
That would be really neat. FileMerge looks pretty great. It isn't too fun to edit with though.
Exactly.
On Fri, 18 Feb 2005 17:33:25 +0100, Fred B. fredb7@starflam.com wrote:
Common' several people, stand up! ;)
I'll stand next to you. A good diff is as necessary as a good editor.
-
Allan Odgaard -
Chris Thomas -
Eric Hsu -
Fred B. -
Kai von Fintel -
Ned Nieuws -
Robert M.Zigweid -
Sune Foldager -
Torsten Becker