On Fri, Jan 29, 2010 at 11:24 AM, Gil Shwartz <[email protected]> wrote:
> Indeed the read code is a player in the clone game, but other parts of > Leo should participate as well. This is exactly where we disagree. We can imagine extending the read logic, say with a postpass, to handle clone battles more intelligently. That would be a "contained" solution. But to do more than that would be most unwise, imo. If we can not, at read time, resolve clone battles, then we are asking for big big trouble. The ramifications throughout Leo are simply mind boggling. Leo's read and write code are stable because the are completely stateless. We can't have unresolved data hanging around. It's just out of the question. The read code could certainly flag dubious resolutions and let the user, perhaps with the aid of a plugin, undo whatever choices the read code might make. But that's really a nit. The fundamental constraint is that Leo's data *always* be in a known, stable state. 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.
