[TxMt] Req: Compare docs-Diff

Eric Hsu erichsu at math.sfsu.edu
Fri Feb 18 18:26:59 UTC 2005

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" 

>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
Eric Hsu, Assistant Professor of Mathematics
San Francisco State University
erichsu at math.sfsu.edu

More information about the textmate mailing list