> What commands do is different from what scripts do. Commands are
> supposed to handle dirty bits, though perhaps some do not.
I see. I will keep this distinction in mind so I can know what to expect.
-------- Original Message --------
Subject: Re: Unmark-all command [was: Q: Outline icon has red line that
won't go away]
From: Edward K. Ream <[email protected]>
To: [email protected]
Date: Sunday, December 12, 2010 9:04:51 AM
On Sat, Dec 4, 2010 at 7:57 PM, taa, Leo Newbie<[email protected]> wrote:
When I toggle the mark (red) in a node, it's flagged as dirty, and the
overall file is flagged as changed. Whether the state changes from marked to
unmarked, it still gets flagged as dirty. This works as I would expect.
When I execute the unmark-all command on the entire outline, any nodes
changed from marked to unmarked are flagged as dirty and the overall file is
flagged as changed. This also works as I would expect.
When I execute the unmark-tree script, any nodes changed from marked to
unmarked are NOT flagged as dirty, and neither is the overall file flagged
as changed.
If "marking nodes as dirty happens automatically", then what is the reason
unmark-tree isn't "automatically" flagging the nodes as dirty, when
unmark-all DOES, and toggling a single node DOES?
What commands do is different from what scripts do. Commands are
supposed to handle dirty bits, though perhaps some do not.
In addition, there are serious performance issues due to redrawing and
due to clones. Thus, Leo's core takes care to compute dirty bits in
the most efficient way possible.
The general idea is that v.setDirty and v.clearDirty set only the
bits, but p.setDirty is quite expensive: it calls
p.setAllAncestorAtFileNodesDirty. Thus, the unmark-all command (the
unmarkAll method) initially calls p.v.setDirty, and then computes
list of dirty vnodes.
You could call this a minor bug: ancestor @file nodes never get marked dirty.
There is another complication: **undoing** an operation that sets a
mark is not the same as an operation that clears the mark. The former
may clear the appropriate dirty bits, while the latter will always set
dirty bits.
In short, your script needs to take care to save and restore any
needed state of the dirty/marked bits. If only a few nodes are
involved, it would be tolerable to call p.setDirty, but if many are
involved you must be more careful, perhaps even more careful than
Leo's own core code.
HTH.
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.
