Hello, Couldn't the 'patch' command do this? E.g., Vim#1 has made some changes to example.c (but not saved them), and Vim#2 makes some different changes and saves them. Vim#1 sees that example.c has changed, and makes a diff between the new example.c and what it originally was, and also makes a diff between Vim#1's modifications and what example.c originally was, patches the original with both those diffs and *bingo* you have the merged file (so far as you can trust the patch utility).
Shouldn't this be possible through the autocommands? I think you could write this as a plugin, Yakov. regards, Peter --- Gene Kwiecinski <[EMAIL PROTECTED]> wrote: > >>I'd be seriously uncomfortable with that as a "feature". Imagine > >>absentmindedly editing the same file 2x or more. Make some changes in > >>one instance, make different changes in another instance, save/quit > the > >>first, save/quit the second, trash all the edits made in the first > >>instance. > > >In the orininal post, I wrote about the feature where two+ instances > >of vim show and merge changes made by other instances. With > >such "collaboration" enabled, the 2nd instance would show and merge > >changes made by 1st instance, and 1st instance would absorb, merge > >and show changes made by 2nd instance. In this scenario, loss of > >edits does not happen. So I don't underastand why you say you are > >against it if it avoids exactly what you cited as unwanted ? > > >>-- Ability of N instances of vim to absorb, merge and show changes > >>to the same file made by other running vim instances > > Because I don't trust such mechanisms. Especially if editing the same > block of text/code/etc., where subtle changes in a program can be > disastrous. > > Eg, just yesterday, I wanted to "split off" some functionality to a > separate variable, so made another one called "avg" from the original > "average". What if the second instance just "assumed" that I wanted to > make similar changes to the original instance of "average" when I in > fact wanted/needed it to be the same. There's no easy way to "absorb" > or "merge" changes automagically; sometimes even the order of > implementation is rather significant. Just ask anyone who uses > sccs/rcs/etc., about forked code, and some of the nightmares trying to > reconcile different disparate versions. > Send instant messages to your online friends http://au.messenger.yahoo.com
