Edward,
Thanks very much for the response! One followup below (are the nodes
stored in a hash), and some other comments that can be ignored (maybe
me just talking to myself).
On Tuesday 02 December 2008 11:47 am, Edward K. Ream wrote:
> I like this kind of question. It's a low-level question that requires
> some high-level understanding, or something like that :-)
Glad you like it! ;-)
> The simple answer is that all of Leo's data is contained in nodes. As
> you suggest, nodes are always resident in memory. Leo creates nodes
> when reading .leo files, when reading derived files, and when
> inserting nodes as the result of commands. See the files
> leoFileCommands.py, leoAtFile.py and leoEditCommands, respectively,
> for these three cases.
>
> leoFileCommands.py creates nodes using sax. This is complicated. See
> leoPy.leo,
> Code-->Core classes-->@thin leoFileCommands.py-->Reading-->Sax
(reading)
I google sax and read the short wikipedia article. So sax is what
parses the data.
Are the nodes stored in something like a hash?
> leoAtFile.py creates nodes as the result of handling sentinels. See
leoPy.leo:
> Code-->Core classes-->@thin leoAtFile.py-->at.Reading-->Reading (4.x)
Didn't find that with the old copy of Leo that I have--will have to
download a new copy in the next day or so (I'm back at
leo-4-4-2-1-final).
> > When a node (or headline) is actually displayed in Leo, is an
additional
> > copy of that text made, or does the "text widget" simply access the
one
> > copy of text in RAM by means of something analagous to a pointer
> > (reference, ..., or whatever)?
>
> Not quite the correct question. In both the Tk and Qt gui, headline
> and body text is passed between the gui and Leo, but the details don't
> matter. The important point is that the gui code must ensure that
> Leo's nodes (in memory) always match what is visible in the gui.
Ok, I'll have to think about that a little. My "concern" was whether
two copies of some of the text are maintained.
My fat, dumb, and happy approach to folding in nedit started with the
idea of storing all the text in a new 2nd data structure, then removing
all folded data from, in essence, the text display widget. (And
restoring it from that 2nd data structure on unfolding.)
> > 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 ...
regards,
Randy Kramer
--
I didn't have time to write a short letter, so I created a video
instead.--with apologies to Cicero, et.al.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
