[TxMt] Req: Compare docs-Diff

[Eric Hsu]

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