On Sun, Aug 29, 2010 at 8:21 PM, Terry Brown <[email protected]> wrote:
>> The code in putTnode writes uA's for *all* nodes, which is also
>> correct because Leo only writes <t> elements for the top-level nodes
>> of @thin, @edit and @auto trees.
>
> Based on the snippet below, I suspect it only writes t nodes for the top
> level of @file, not @thin/edit/shadow/auto. It would be great if it wrote a
> t node for all of them.
>
> <vnodes>
> <v t="tbrown.20100824112457.10015"><vh>@edit 1.txt</vh></v>
> <v t="tbrown.20100824112457.10017"><vh>@file 2.txt</vh></v>
> <v t="tbrown.20100824112457.10019"><vh>@shadow 3.txt</vh></v>
> <v t="tbrown.20100824112457.10021"><vh>@auto 4.txt</vh></v>
> <v t="tbrown.20100824112457.10023"><vh>@thin 5.txt</vh></v>
> </vnodes>
> <tnodes>
> <t tx="tbrown.20100824112457.10017"
> annotate="7d710055087072696f7269747971014b02
> </t>
> </tnodes>
Thanks for this.
The relevant code is in putVnode, specifically the forceWrite var. We
can write <t> elements simply by ignoring this var when writing <t>
elements. That is, we would change
<< Set gnx = vnode index >> from::
gnx = g.app.nodeIndices.toString(v.fileIndex)
if forceWrite or self.usingClipboard:
v.setWriteBit() # 4.2: Indicate we wrote the body text.
to:
gnx = g.app.nodeIndices.toString(v.fileIndex)
v.setWriteBit() # 4.2: Indicate we wrote the body text.
(Actually, the entire section is wretched style. The code should be
placed inline :-)
**Important**: the real question is, do we dare write <t> elements for
@auto, etc?
There are three files to consider: leoFileCommands.py, leoAtFile.py
and leoImport.py.
1. leoFileCommands.py:
The addition of a new <t> element *might* work as desired without side effects:
A: getSaxUa never alters the node structure, it merely adds uAs.
B: createSaxVnode *does* set the body text from (in effect) the <t> element.
Presumably the leoAtFile read code will override this effect, but
it's tricky.
2. leoAtFile.py:
The crucial methods are at.createThinChild4, at.createNewThinNode and
at.terminateNode (at.findChild4 exists only to read *old-style* @file
nodes.)
at.terminateNode (via its helper at.terminateBody) just jams the new
text into the node, with many complications arising from the desire to
report changed nodes. Happily, no warnings are ever given for the root
node (perhaps because no <t> element existed for the root node??), so
we should be good to go.
3. leoImport.py:
readOneAtAutoNode and its helper, createOutline, are the methods in question.
Again happily, createOutline jams the empty string into the body
string initially, so body text arising from a <t> element will
probably be totally ignored.
The conclusion seems to be that we can ignore forceWrite in putVnode
when deciding whether to write <t> elements. This *might* be a
legitimate change. However, it is way too dangerous to do in the
trunk.
If you are interested, please create a new branch, and test for
several days after all unit tests pass.
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.
