On Wed, Jan 27, 2010 at 8:56 AM, Edward K. Ream <[email protected]> wrote:
>> Every time a clone node is moved, Leo can evaluate if it becomes an external >> clone node and if it does and the clone entity has more than one >> external clone nodes, > > I absolutely refuse to do this, and I will not accept a plugin that > attempts to do this. Still true, but this remark should be taken with a grain of salt :-) I'm not going to change Leo's data structures, but we can attempt to solve the problem in much simpler ways. After some thought, I realize the essence of the problem involves only Leo's read code. There are several possible approaches. 1. The simplest thing that could possibly work. When a conflict happens, presumably in the atFile.read code, Leo will remember the completing versions in, say, c.conflictingNodesList. Entries will record the vnode and all the conflicting versions of the text. A plugin could use an open2 hook to attempt to choose the proper version, possibly by putting up a dialog. 2. More complicated, but perhaps more useful. Mark some trees with an @master directive. Presumably, @master and @all would work together to provide a *single* external file that contains master copies of data. It's vital to understand that being a "master" node in this sense affects only Leo's read logic, and *nothing* else. 3. Scripting solutions, within Leo or without (xslt). Always open ended, but I have no great ideas at present. Just the start of some ideas. I wanted to throw this out quickly so people will realize I'm not as negative on this subject as my initial words may have implied. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
