Fernando Ramos <greenfoo@xxxxxx> writes: > The nice thing about this approach is that, as we have seen, it is generic > enough to rule all current variants obsolete. I am not a vimdiff user (or mergetools in general---I should use it as appropriately from time to time myself), but it would be great if such a general "layout rule language" can be used to replicate the existing variants. > So, please let me know what you think about this: > > * Do you like this approach? Or am I trying to crack a nut with a sledgehammer > by making the whole thing too complex? > > * In case you like it, should we keep the old "vimdiff1", "vimdiff2" and > "vimdiff3" variants for backwards compatibility? > If the answer is "yes", I'll just alias them to the new "layout" mechanism > so that the amount of extra code needed for supporting them is minimal. It is great that the new "description based layout" can replicate the existing variants, and it is natural migration path to redo the existing variants with the new mechanism once the dust settles as a separate step. The end-users should be able to rely on their existing configuration to keep working the same way as they are used to. Thanks.
