>>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.
