On Mon, Dec 1, 2008 at 10:35 AM, Randy Kramer <[EMAIL PROTECTED]> wrote:
>
> I'm primarily a lurker here, but I have a question--I could research
> this on my own, but I thought I'd start by just asking.

I like this kind of question.  It's a low-level question that requires
some high-level understanding, or something like that :-)

> Can anyone provide a simple explanation (or maybe just answer the
> following questions) about how text (nodes and headlines) is handled in
> Leo when a file is "resident" in Leo?

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)

leoAtFile.py creates nodes as the result of handling sentinels.  See leoPy.leo:
Code-->Core classes-->@thin leoAtFile.py-->at.Reading-->Reading (4.x)

Commands typically use high-level commander methods, like
c.insertHeadline, which calls mid-level position methods to insert or
clone a node.  These mid-level methods call low-level methods that
alter actual data structures.  You should *never* call these low-level
methods directly.

> I presume all the text (nodes and headlines) are stored in memory at
> that point (i.e., rather than being paged in or similar from disk)?

Yes.  It is possible to use zodb to store Leo's nodes (instead of .leo
files), but iirc even then nodes actually get loaded into memory for
use.

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

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

> OTOH, recently I heard about Scite.

I often use Scite for quick editing.

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

Reply via email to