On Mon, Aug 30, 2010 at 10:34 AM, Edward K. Ream <[email protected]> wrote:
> 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.

I would be interested in testing.

@auto represents the bridge between Leo and the big world outside Leo.
As such, I consider the uA of an @auto <file> node crucial, a critical
element of leveraging Leo as a tool for managing the data of the world.

As always, I wish it wasn't a pickle by default, but that's another story.

:-]

Thanks,
Kent

>
> 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.
>
>

-- 
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.

Reply via email to