On Mon, Jun 8, 2009 at 12:57 PM, Ville M. Vainio <[email protected]> wrote:
> > I understand it's advised against to have a clone across 2 thin files. > > However, @thin qtNotes.txt does exactly this. What I want to avoid is a situation in which two different .leo files or @thin nodes each have a presumptive claim to "own" a node. @thin qtNotes.txt is a bit safer for several reasons: 1. qtNotes.txt appears earlier in leoPy.leo than any of the other @thin nodes, so changes in @thin nodes will override any code in qtNotes.txt. In other words, if there is a mismatch between the two copies, we presume that the change was made in one of the .py files. 2. qtNotes.txt uses @all, which is a way of saying that the organization and contents of the qtNotes.txt don't matter much. This makes me slightly > nervous, since I never commit that file (or anything apart from .py > files in the first place), and I'm afraid sometimes valuable code in > .py file could be thrown away because code in .txt file will take > precedence. That's highly unlikely to happen, because qtNotes.txt will likely be in synch with all the .py files when you commit. The only thing to avoid would be to make external changes in qtNotes.txt rather than the "primary" files. > Perhaps qtNotes.txt stuff should be moved to plain tree in .leo file, > as opposed to @thin node? That would defeat the main purpose of @thin qtNotes.txt, namely that it can change significantly without requiring any changes in leoPy.leo (or rather leoPyRef.leo). In my mind, it's important to change leoPyRef.leo as little as possible. > Also, perhaps there should be a loud warning > when the user does this. It's a fact of life that in VCS environment, > files *will* get out of sync. I'm not sure what you mean by "this", but I don't recall any serious problems with qtNotes.txt. Some of these concerns could be solved by this ingenious hack (correct > me if there is something like this in place already): > > Do not read in @thin nodes in tree order - rather, read them according > to the extension, and have .txt mean "read this node last". Users > could be advised to hold all their "note collector" trees as .txt > files (and warned accordingly if this is not the case). Reading @thin qtNotes.txt is precisely what we want. The hack would cause endless confusion, and would make already difficult code more complex. You are right to be a bit concerned about cross-file clones. And a comment in the @root qtNotes.py node saying that the node should precede all other @thin nodes would be a good idea. But I don't think any other action is needed. 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 -~----------~----~----~----~------~----~------~--~---
