It appears this is not fully true. Marking a non @<file> parent node only sets @<file> child nodes recursively to dirty, non @<file> nodes are recursively left clean. So If the non @<file> nodes are left alone, why not also leave the @<file> nodes alone? I am trying to understand the inconsistency.
On Tuesday, April 26, 2016 at 11:17:52 AM UTC-4, john lunzer wrote: > > Perhaps I should have been more specific. Marking is triggering a > recursive dirty setting regardless of node type. There is no reason > marking a non @<file> parent node should set all child nodes (@<file> or > not) dirty. In this case the parent has no bearing on the content or > position of the child nodes so it should not mark it dirty. > > On Tuesday, April 26, 2016 at 10:46:47 AM UTC-4, Edward K. Ream wrote: >> >> On Mon, Apr 25, 2016 at 7:27 PM, john lunzer <[email protected]> wrote: >> >> > >> There is no reason marking a parent node should set all the children >> dirty. >> >> Yes, there is. >> >> p.setAllAncestorAtFileNodesDirty is required so that the write logic >> knows which @<file> nodes to write. To my knowledge, these are the only >> ancestor nodes that are marked dirty. >> >> EKR >> > -- 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.
