On Wed, Dec 3, 2008 at 11:21 AM, Randy Kramer <[EMAIL PROTECTED]> wrote:
> I google sax and read the short wikipedia article. So sax is what
> parses the data.
Correct. Google and the wikipedia are good sources, but I recommend
starting with leoPy.leo, the tree 'Code-->Core classes-->@thin
leoFileCommands.py--><< define sax classes >>'
Sax is actually pretty easy to use. You start sax, and then sax calls
handlers that are defined in the saxContentHandler class. Apparently
the node << define dispatch dict >> creates the correspondence between
xml elements and handlers. These handlers create saxNodeClass
objects. Iirc, a post-pass (triggered by an 'end' element handler)
then creates the actual tnodes and vnodes.
I said 'apparently' above because I don't remember details, I just
read the code, same as anyone. The only thing I remember is that sax
calls handlers, the handlers create data, and eventually the data
turns into nodes.
> Are the nodes stored in something like a hash?
No. Nodes have a __hash__ function, but that's not significant.
During the "unified node" experiment (which succeeded, but which
ironically turned out not to be very interesting), the lowest-level
data structures changed. Formerly, nodes where linked together with
_next, _back, _parent and _firstChild "pointers". Now a node's
_children field (a Python array) holds an ordered list of the node's
children.
That's about all I remember. Details are tricky and handled by
low-level vnode, tnode and position methods. For details, see
leoNodes.py. But the details should not matter to you, or anyone else
(including me). All that really matters is that clones can be
represented efficiently, and can be created and destroyed quickly in
O(constant) time without scanning the entire tree.
> Ok, I'll have to think about that a little. My "concern" was whether
> two copies of some of the text are maintained.
Leo takes great care in synchronizing the various representations of
headline and body text. That's what makes doing a gui plugin
non-trivial. Other than that, it doesn't matter whether text is
copied or not: it has no effect on performance.
>> > Maybe the storage mechanism used by Leo for folded text will be
> useful
>> > in Nedit (ignoring that Nedit is programmed in C and Leo in Python).
>>
>> I would agree with this if you replace "storage mechanism" by "the
>> code in leoNodes.py". Leo's position, tnode and vnode classes could
>> be used in any editor. None of this code depends in any way on any
>> other part of Leo's code. Oh yes, similar statements apply to
>> commander iterators defined in leoCommands.py.
>
> I'll have to think about that--not too sure how easily I can integrate
> python code into a C application. Or, maybe the other way is to create
> a new python application and utilize ("wrap"?) the nedit C code as the
> text widget ...
I highly recommend basing everything you can on Python. It's a common
approach, and I've never ever heard anyone regretting that approach.
You always want to "deprecate" (hide) C code. That way, you can add
features in Python.
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
-~----------~----~----~----~------~----~------~--~---
