On Jan 21, 2:09 pm, Gil Shwartz <[email protected]> wrote: > Sometimes to decide what to do with the broken clone, you do need the > context. Therefore I (also) suggest adding these UI enhancements:
This is a hard problem, and I distrust solutions such as you propose. Conflicting clones are rare, and when they do happen they will be an unwelcome surprise. In such situations it is *hopeless* to expect the user to do something reasonable. My typical reaction is, "oh shit, what do I do now?". This is not the time for complex decision making! So we can't assume the user will do *anything*, and certainly not anything reasonable :-) After struggling with my words for awhile, I think what I am trying to say is this: we want an error recovery scheme that "just works" without *any* input from the user. Assume, as I do about myself, that in such situation the user goes (temporarily) brain dead. Furthermore, the error reporting scheme must survive saving and reloading the .leo file. That is, saving and reloading the .leo file should leave the nodes created by the error recovery scheme unchanged. True, your proposal doesn't require instant action from the user, but I wonder whether it addresses these concerns. I don't want "error recovery marks" lying around. Indeed, Leo presently marks nodes that have surprisingly changed, and I always find such marks both useless and (later) annoying. These are just thoughts, and I suppose I could be persuaded to consider them more seriously, but imo such complications are an indication of failure to recover from errors. 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.
