On Sat, Feb 24, 2018 at 7:31 AM, vitalije <[email protected]> wrote:
It seems that p.setDirty propagates dirty status not only to the ancestors > but also to the all descendant nodes as well, nodes that are roots of > external files (v.isAnyAtFileNode()). At first I thought this was > unnecessary, but then I realized this is probably to allow that change in > the ancestor can change resulting path of the descendant file nodes which > would require those nodes to be written on the next save operation. > Yes. If this is the reason to propagate dirty status down the tree, then perhaps > it can be skipped if this node doesn't contain at-path or any other > directive that might cause need for writing descendant file nodes. That > would be almost always the case. > I have forgotten all details of the code and its motivations. Changing for example top level node "Code" in LeoPyRef.leo causes more than > 160 files to be set dirty on the next save command, which seems to me wrong. > As you say, it's probably safe not to set descendant nodes dirty if the top node contains no directive that affect descendant @<file> nodes. Since "Code" contains only @language python, you would think all is well. Alas, it's not enough to look at the present contents of a node. One must compare this with the previous contents, to ensure, say, that an @path directive has not just been deleted. This will be tricky, but there might be a clever way to do it. My concern is that the affected code will be far removed from p.setDirty and its helpers. I would much rather try to write 160 files, without effect, than to get this wrong, now or in future. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
