New persistence code ready for testing!

[Edward K. Ream]

As of rev 25101ddf3b0c... Leo now saves and restores clone links and uA's in @auto trees!

For example, use the todo plugin to add an icon to a node in an @auto file.  Save the file and reload.  The icon will still be there.

Ditto for clones links for between node a node C inside an @auto file and a cloned node C outside the @auto file.

Such links should persist *provided* you don't change the outline structure (including headlines) of the @auto file outside of Leo.

All changes are *lightly* tested.  Please report any problems immediately.  To disable the new code, set new_auto = False at the start of leoAtFile.py.

Edward

[Kent Tenney]

On Mon, Jul 14, 2014 at 8:48 AM, Edward K. Ream <edre...@gmail.com> wrote:
> As of rev 25101ddf3b0c... Leo now saves and restores clone links and uA's in
> @auto trees!
>
> For example, use the todo plugin to add an icon to a node in an @auto file.
> Save the file and reload. The icon will still be there.
>
> Ditto for clones links for between node a node C inside an @auto file and a
> cloned node C outside the @auto file.
>
> Such links should persist *provided* you don't change the outline structure
> (including headlines) of the @auto file outside of Leo.

This is a show-stopper for me, and probably evidence of my outlier status.
I'm as likely to work in vim as Leo, on-the-run work done in vim, more formal
sessions from Leo. If changes outside Leo break @auto, it's no longer @auto
in my book.

The question seems to be: 'which is canonical, myfile.py, or myfile.leo' for
true leonistas, the latter is fine, I need the former.

All this means is that you are solving a problem that I don't have, but one
that presumably, many others do.

From the next message
>But how often do you, in fact, change outline structure outside of
>Leo? And how often do you change the *names* of imported things
>outside of Leo? Not all that often, I'm guessing.

BZZZZZT wrong guess, as described above.
(and, evidenced by the recurring mention of the 'refresh from disk' bug)

I'll continue looking at @auto persistence via back-end db.

Thanks,
Kent

>
> All changes are *lightly* tested. Please report any problems immediately.
> To disable the new code, set new_auto = False at the start of leoAtFile.py.
>
> Edward
>

> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Mon, Jul 14, 2014 at 9:22 AM, Kent Tenney <kte...@gmail.com> wrote:

>> Such links should persist *provided* you don't change the outline structure
>> (including headlines) of the @auto file outside of Leo.

> This is a show-stopper for me, and probably evidence of my outlier status.
> I'm as likely to work in vim as Leo, on-the-run work done in vim, more formal
> sessions from Leo. If changes outside Leo break @auto, it's no longer @auto
> in my book.

I think you will find that the present scheme will work well for you.
Please try it.

> The question seems to be: 'which is canonical, myfile.py, or myfile.leo' for
> true leonistas, the latter is fine, I need the former.

myfile.py *is* canonical, if I understand you correctly. The new
@auto is exactly the same as the old @auto in this regard. The parser
hasn't changed: you *always* get the outline structure of the imported
file. Period.

Persisted data have got to be stored somewhere. In the present
scheme, they are stored in the @persistence tree, but it really
doesn't matter where the data are stored. Putting them in a db
changes nothing.

The question isn't which data is canonical, the question is how to
link data with incoming nodes.

> All this means is that you are solving a problem that I don't have, but one
> that presumably, many others do.

I have solved the one and only problem that we have been talking about
for these many years: how to associate uA's and clone links with
imported outlines.

You are asking for the impossible if you demand that the links between
persisted data and incoming nodes *never* break. Only sentinels with
gnx's provide truly unbreakable links.

Bookmarks (unl's) along with a flexible (but not perfect) algorithm
that associates the unl's of incoming nodes with gnx's (and hence,
persisted data) seem like the only possible approach. If you want
something better than bookmarks, please explain how it might possibly
work.

Edward

[Kent Tenney]

I think I see the problem.

>>> Such links should persist *provided* you don't change the outline structure
>>> (including headlines) of the @auto file outside of Leo.

I read this as changing outside Leo breaking the import, not just the inevitable
issue of 'here's an unknown node'.
I bet the changed nodes get a fresh gnx and a blank uA correct?
As you say, that's all that is possible.

Sorry for the noise.

>
> Bookmarks (unl's) along with a flexible (but not perfect) algorithm
> that associates the unl's of incoming nodes with gnx's (and hence,
> persisted data) seem like the only possible approach. If you want
> something better than bookmarks, please explain how it might possibly
> work.
>
> Edward
>

[Edward K. Ream]

On Mon, Jul 14, 2014 at 10:06 AM, Kent Tenney <kte...@gmail.com> wrote:

> I think I see the problem.
>
>>>> Such links should persist *provided* you don't change the outline structure
>>>> (including headlines) of the @auto file outside of Leo.

> I read this as changing outside Leo breaking the import, not just the inevitable
> issue of 'here's an unknown node'.

The import will be fine.

> I bet the changed nodes get a fresh gnx and a blank uA correct?
> As you say, that's all that is possible.

Exactly.

> Sorry for the noise.

Whew! I'm glad we're on the same page now :-)

Edward

[Terry Brown]

On Mon, 14 Jul 2014 06:48:18 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

> As of rev 25101ddf3b0c... Leo now saves and restores clone links and
> uA's in @auto trees!
>
> For example, use the todo plugin to add an icon to a node in an @auto
> file. Save the file and reload. The icon will still be there.
>
> Ditto for clones links for between node a node C inside an @auto file
> and a cloned node C outside the @auto file.
>
> Such links should persist *provided* you don't change the outline
> structure (including headlines) of the @auto file outside of Leo.

Ok, this took me a while to parse (haha), but Kent's got it well
clarified now :-)

So how hard does the new code try to recover from breakage? Does it
use the new indexed UNLs to fall-back on position index when headlines
fail? I guess it's a more sensitive case than bookmarks, where Leo can
basically say "I can't find that, but it used to be here, if that
helps", and let the user decide. In the import case you could only
fall back on the position index when the matched node was not also
matched by a headline list. I.e.

class Foo
def __init__
def otters
def recieve_data
def send_data

if it's simply a change from recieve_data to receive_data, falling back
on position index would be great. But if the change was to

class Foo
def __init__
def otters
def send_data
def receive_data

then headline search would fail and index search should fail because of
the competing headline search match for send_data.

Also, does the new code use the new UNL's repeated headline count to
match the right headline when headlines are repeated? Repeated
headlines in python code would be contrived, e.g.

def fooble(arg1):
"this doesn't work, retained for historical interest"
code
code

def fooble(arg1):
"working version"
code
code

although this is dumb but valid:

PROCESSORS = []

def processor(args, args):
code

PROCESSORS.append(processor)

def processor(args, args):
different code

PROCESSORS.append(processor)

but repeated headlines in other languages might be entirely reasonable,
"div" in parsed HTML being a trivial example.

So when breakage does occur, does the new code make a list of nodes not
found with their uA data still attached? Because that could be really
useful when valuable uA data was involved.

Final questions:

Are gnxs persisted?

What are the differences between this and @shadow?

Cheers -Terry

[Kent Tenney]

Indeed, hate to see fisticuffs on this list [-;

Initial test is REALLY exciting, in addition to complete support
for the 'choices' stuff, the timestamps in uA are persistent ...

Amazing stuff Edward.

Thanks,
Kent

[Edward K. Ream]

On Mon, Jul 14, 2014 at 10:41 AM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

> So how hard does the new code try to recover from breakage?

At present, Leo attempts no error recovery.

> Does it use the new indexed UNLs to fall-back on position index when headlines fail?

I have no idea what you mean by this. If a bookmark (unl) can't be
associated with a node (headline) then the node's gnx doesn't change:
it won't be a clone of any node an it won't have any uA.

> I guess it's a more sensitive case than bookmarks, where Leo can basically say "I can't find that, but it used to be here, if that helps", and let the user decide.

That might happen later.

> In the import case you could only
> fall back on the position index when the matched node was not also
> matched by a headline list. I.e.
>
> class Foo
> def __init__
> def otters
> def recieve_data
> def send_data
>
> if it's simply a change from recieve_data to receive_data, falling back
> on position index would be great. But if the change was to
>
> class Foo
> def __init__
> def otters
> def send_data
> def receive_data
>
> then headline search would fail and index search should fail because of
> the competing headline search match for send_data.

All of this is what I am calling AI. I would prefer not to do
anything in such cases. At what point does an (obvious???) misspelling
turn into a "real" change.

Rather than try to answer such deep questions, I would prefer to
accept the inevitable: some links to gnx's will break. It would be
easy to report such breaks, as you suggest. In fact, pd.restore_gnx
will do this if the trace var is True.

> Also, does the new code use the new UNL's repeated headline count to match the right headline when headlines are repeated?

No. That's on purpose.

> Repeated headlines in python code would be contrived, e.g. [snip]

I agree. Pylint will report duplicate function/method in such cases.

> but repeated headlines in other languages might be entirely reasonable,
> "div" in parsed HTML being a trivial example.

Interesting. Imo, the solution for html would be to add more to the
imported headline :-)

> So when breakage does occur, does the new code make a list of nodes not found with their uA data still attached? Because that could be really useful when valuable uA data was involved.

Interesting idea. pd.update_after_read_foreign_file could easily
create a list/tree of nodes with potentially valuable uA's, with
headlines derived from the unmatched corresponding unl in the @gnxs
node. This would work much like the "recovered nodes" nodes that Leo
creates when reading @file nodes.

Having said that, my experience is that such recovered data are rarely
used, even when the data are text. I suspect recovered uA's would
hardly ever be used.

> Are gnxs persisted?

Yes. The @gnxs node contains pairs of lines associated the
(persisted) gnx's with unl's. If the match is made, pd.pd.restore_gnx
restores the gnx of the imported node by calling
p2._relinkAsCloneOf(p1). It's slick. If the match can't be made, the
node retains the (new) gnx given to it by the importer, with a
timestamp that reflects the time that the node was imported.

> What are the differences between this and @shadow?

Good question. @shadow recreates the outline using the Leo sentinels
in the so-called private file. All gnx's (and so clone links and
uA's) are preserved.

@shadow works by diffing text, namely the diffs between the public
file and the private file (stripped of sentinels). The public file
never has any sentinels, so all changes to the public file get
translated into text in the original nodes in the private file. With
@shadow, all changes to the outline structure, **no matter how big**,
are "shoe-horned" into the outline structure of the private file.

In contrast, the @auto importers have no access to any sentinels.
They create a tree based solely on the logical structure of the
imported file. In particular, headlines in @auto files can only come
from the names of functions, classes and methods.

Aside: The old "new @auto" code tried to rename/retain headlines, but
that created way too many complications. I have no plans to bring
that scheme back.

In short: @auto always give you the correct structure of the imported
file. The @auto importers know nothing of gnx's. @shadow always
preserves the structure of the outline when it was last written,
including gnx's. That may not be great when big changes have been
made.

Edward

[Edward K. Ream]

On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney <kte...@gmail.com> wrote:

>> Whew! I'm glad we're on the same page now :-)

> Indeed, hate to see fisticuffs on this list [-;

Yeah, I was about to give you a phone call ;-)

> Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ...

Excellent. What do you mean by "choices stuff"?

> Amazing stuff Edward.

Thanks. *That's* the response I was expecting. Hehe.

It's very satisfying that the code is so much simpler than before.

At present, I plan only two more changes:

1. As discussed previously, pd.find_position_for_relative_unl will be
rewritten to be more flexible when searching for matches between unl's
and the incoming imported outline. This will reduce broken links.

2. The clean-persistence-tree command will remove @data nodes that do
not correspond to any existing foreign file (for now, read @auto
tree).

Edward

[Terry Brown]

On Mon, 14 Jul 2014 11:29:19 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

> On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney <kte...@gmail.com>
> wrote:
>
> >> Whew! I'm glad we're on the same page now :-)
>
> > Indeed, hate to see fisticuffs on this list [-;
>
> Yeah, I was about to give you a phone call ;-)
>
> > Initial test is REALLY exciting, in addition to complete support
> > for the 'choices' stuff, the timestamps in uA are persistent ...
>
> Excellent. What do you mean by "choices stuff"?
>
> > Amazing stuff Edward.
>
> Thanks. *That's* the response I was expecting. Hehe.
>
> It's very satisfying that the code is so much simpler than before.
>
> At present, I plan only two more changes:
>
> 1. As discussed previously, pd.find_position_for_relative_unl will be
> rewritten to be more flexible when searching for matches between unl's
> and the incoming imported outline. This will reduce broken links.

I asked a vague question about the status of vc.find_absolute_unl_node
and vc.find_position_for_relative_unl the other day, what I meant was,
what do they do that g.recursiveUNLFind doesn't? It seems like we have
two methods to do the same thing, and I think it's already caused
confusion dev. wise, when the smarter bookmarks were being developed
and the vc.* commands were updated even though they weren't relevant.

Cheers -Terry

[Kent Tenney]

On Mon, Jul 14, 2014 at 11:29 AM, Edward K. Ream <edre...@gmail.com> wrote:
> On Mon, Jul 14, 2014 at 10:46 AM, Kent Tenney <kte...@gmail.com> wrote:
>
>>> Whew! I'm glad we're on the same page now :-)
>
>> Indeed, hate to see fisticuffs on this list [-;
>
> Yeah, I was about to give you a phone call ;-)
>
>> Initial test is REALLY exciting, in addition to complete support for the 'choices' stuff, the timestamps in uA are persistent ...
>
> Excellent. What do you mean by "choices stuff"?

The 'left' and 'right' buttons which offer multiple node contents
to be available from the back end db, was posted as lndb.py plugin.

>
>> Amazing stuff Edward.
>
> Thanks. *That's* the response I was expecting. Hehe.
>
> It's very satisfying that the code is so much simpler than before.
>
> At present, I plan only two more changes:
>
> 1. As discussed previously, pd.find_position_for_relative_unl will be
> rewritten to be more flexible when searching for matches between unl's
> and the incoming imported outline. This will reduce broken links.
>
> 2. The clean-persistence-tree command will remove @data nodes that do
> not correspond to any existing foreign file (for now, read @auto
> tree).
>
> Edward
>

[Edward K. Ream]

On Mon, Jul 14, 2014 at 11:49 AM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

> I asked a vague question about the status of vc.find_absolute_unl_node
> and vc.find_position_for_relative_unl the other day, what I meant was,
> what do they do that g.recursiveUNLFind doesn't?

Thanks for this reminder. I'll look into g.recursiveUNLFind.

EKR

[Edward K. Ream]

As an exercise, I am going to try to find something simpler  pd.find_position_for_relative_unl.  I don't believe child indices have much hope of improving matches during @auto: I would rather have links break than link to the wrong node.

Edward

EKR

[Terry Brown]

On Tue, 15 Jul 2014 04:39:06 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

>

Use of indices by g.recursiveUNLFind is optional though, so there may
still be duplicated functionality. I won't have time today, but I can
try and make g.recursiveUNLFind a bit clearer, if that helps.

On a different topic, somewhat. It seems that the uA persisting code
really should try and save uA info. on nodes it can't match, otherwise
you're making an assumption the uA info. isn't really valuable. In
some cases it may not be, but you can't assume that's always true. So
what I was thinking was that the orphan nodes could have an UNL (in
their uAs :-) which points to the best guess imported node, perhaps
with a couple of helper commands `orphan-node-goto-best-guess`,
`orphan-node-copy-uA`, and `orphan-node-paste-uA`

Not that this needs to be done immediately or anything, I haven't even
played with the new code yet. It seems to me that the biggest payoff
may be the persisting gnxs, really.

Cheers -Terry

> Edward
>
> >
> > EKR
> >
>

[Edward K. Ream]

On Tue, Jul 15, 2014 at 7:04 AM, 'Terry Brown' via leo-editor

> It seems that the uA persisting code really should try and save uA info on nodes it can't match...

> So what I was thinking was that the orphan nodes could have an UNL (in
their uAs :-) which points to the best guess imported node, perhaps

with a couple of helper commands...

There is no such thing as a "best guess". The present code will use
any unl whose tail matches any node in the @auto tree. If that
doesn't work, Leo could create such a node, and put the uA in it. I
suppose one could then have a copy uA command. Not very exciting,
imo, but it might be useful in some situations.

Edward

[Terry Brown]

On Tue, 15 Jul 2014 17:50:21 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

I guess it's a question of what the uA data is - I sometimes store very
valuable data in uAs, but of course up until now never on an @auto
file, in fact typically not in any @<file> type. So I'm not sure what
people would store on nodes in @auto files, but if for example it was
notes on things that need to be done to the code, and if for example
one off the notes was "remember to replace my google password with
prompt for user input before release", and if the note vanished and you
subsequently forgot, you might be saddened by that :-)

Silly example, but it seems in general people won't want data to only
persist sometimes. Of course you did have to make uAs persistent :-)
I think persistent gnxs would have done it for Kent.

So just general interest, what happens when you delete __init__ from
class A, do its uAs get assigned to __init__ in class B? And then
where do B.__init__'s uAs get assigned?

I really should try the code :-)

Cheers -Terry

[Edward K. Ream]

On Tue, Jul 15, 2014 at 8:17 PM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

>> > It seems that the uA persisting code really should try and save uA
>> > info on nodes it can't match...

I agree.

> I guess it's a question of what the uA data is.

No. It's simply a question of where to put restored nodes that
contain the uA's.

> So just general interest, what happens when you delete __init__ from
> class A, do its uAs get assigned to __init__ in class B? And then
> where do B.__init__'s uAs get assigned?

Good point. The code should warn if a node's uA's get assigned twice.

Another warning I've been meaning to mention:
pd.find_position_for_relative_unl should probably warn if two nodes
match according the the new algorithm *and* both matches have the same
length. The matches will *not* have the same length in the example
you mention, so maybe that can be used to disambiguate what node is
meant.

Alternatively, it may be best simply to require an exact match, and
fall back on creating nodes to hold uA's in case no match is found.
I'll think about this.

> I really should try the code :-)

Remember that the *only* way that problems can arise is if you (or
someone else) modifies the @auto node outside Leo.

Edward

[Edward K. Ream]

On Wednesday, July 16, 2014 2:16:45 AM UTC-5, Edward K. Ream wrote:

On Tue, Jul 15, 2014 at 8:17 PM, 'Terry Brown' via leo-editor
<leo-e...@googlegroups.com> wrote:

 
> ...it may be best simply to require an exact match, and fall back on creating nodes to hold uA's in case no match is found.

As of the latest rev, pd.find_position_for_relative_unl contains this code.

    if 1:
        return pd.find_exact_match(root,unl_list)
    else:
        return pd.find_best_match(root,unl_list)

Given our discussion of ambiguous unl's and restoring unmatched uA's, I think the simplest thing that could possibly work is to require exact matches, and to save unmatched uA's somewhere.  So the first part of plan is in place...

Edward

[Jacob Peck]

On 7/16/2014 8:59 AM, Edward K. Ream wrote:
> the simplest thing that could possibly work

Ockham's Razor at work! Good :)

Nice work, Edward. Keep it up!
-->Jake

[Kent Tenney]

First impressions:

- the @auto node icons indicate they are clones

- I'm not sure why the @persistence tree is visible, can it
be used for something? Maybe somehow useful in resolving
issues?

[Edward K. Ream]

On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney <kte...@gmail.com> wrote:
> First impressions:
>
> - the @auto node icons indicate they are clones

Only if they are clones :-)

> - I'm not sure why the @persistence tree is visible, can it be used for something? Maybe somehow useful in resolving issues?

@persistence trees contain all data used to restore gnx's and uA's in
@auto nodes. So yes, they are used for something ;-) They are
visible because all Leo nodes are visible, but the recommended place
for them would be squirreled away in the @startup node.

I just upped code that starts to support @recovery trees in each
per-file @data tree:

1. pd.update_before_write_foreign_file now deletes all children of the
corresponding @data node *except* the first @recovery node (and its
subtree).

2. When an exact match for a unl isn't found, the read code calls
pd.recover_ua_for_gnx. At present, this does nothing, but it will
soon write a child of the @recovery node. Something like::

@recovered-ua <gnx> = <unl>

It's body text will be the pickled ua. This is, I think, about all
that can be done to preserve uA's when an url is not found.

Edward

[Edward K. Ream]

On Wednesday, July 16, 2014 9:14:59 AM UTC-5, Edward K. Ream wrote:

On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney <kte...@gmail.com> wrote:
> First impressions:
>
> - the @auto node icons indicate they are clones

Only if they are clones :-)

I do notice that the icon box has a black border, indicating that the @auto node is dirty.  That's a recent problem.  I'll fix it asap.

EKR

[Kent Tenney]

On Wed, Jul 16, 2014 at 9:14 AM, Edward K. Ream <edre...@gmail.com> wrote:
> On Wed, Jul 16, 2014 at 9:00 AM, Kent Tenney <kte...@gmail.com> wrote:
>> First impressions:
>>
>> - the @auto node icons indicate they are clones
>
> Only if they are clones :-)

No, all of them, none are clones. Sounds like you're already on this.

>
>> - I'm not sure why the @persistence tree is visible, can it be used for something? Maybe somehow useful in resolving issues?
>
> @persistence trees contain all data used to restore gnx's and uA's in
> @auto nodes. So yes, they are used for something ;-)

I was wondering if they are useful in user space. They seem like Leo
bookkeeping. Presumably the user can break persistence by editing in that tree?

They are
> visible because all Leo nodes are visible, but the recommended place
> for them would be squirreled away in the @startup node.
>
> I just upped code that starts to support @recovery trees in each
> per-file @data tree:
>
> 1. pd.update_before_write_foreign_file now deletes all children of the
> corresponding @data node *except* the first @recovery node (and its
> subtree).
>
> 2. When an exact match for a unl isn't found, the read code calls
> pd.recover_ua_for_gnx. At present, this does nothing, but it will
> soon write a child of the @recovery node. Something like::
>
> @recovered-ua <gnx> = <unl>
>
> It's body text will be the pickled ua. This is, I think, about all
> that can be done to preserve uA's when an url is not found.
>
> Edward
>

[Edward K. Ream]

On Wed, Jul 16, 2014 at 9:46 AM, Kent Tenney <kte...@gmail.com> wrote:

> I was wondering if they are useful in user space. They seem like Leo
> bookkeeping. Presumably the user can break persistence by editing in that tree?

Leo has *lots* of nodes that are bookkeeping, including all settings
nodes, @button nodes, @chapters, etc. etc. etc. There is no real
alternative: it would be a nightmare to store persistence data as uAs,
for several reasons:

- The data would not be human readable.
- The code would have to treat persistence uAs differently from normal uAs.

The Leonine way is to use uA's only for special purposes. It would be
quite wrong, imo, to use uAs as hidden notes or to contain most other
valuable data. Almost by definition, valuable data should be
contained in visible nodes. Yes, there could be exceptions, but they
truly *are* exceptions.

Edward

[Kent Tenney]

On Wed, Jul 16, 2014 at 11:48 AM, Edward K. Ream <edre...@gmail.com> wrote:
> On Wed, Jul 16, 2014 at 9:46 AM, Kent Tenney <kte...@gmail.com> wrote:
>
>> I was wondering if they are useful in user space. They seem like Leo
>> bookkeeping. Presumably the user can break persistence by editing in that tree?
>
> Leo has *lots* of nodes that are bookkeeping, including all settings
> nodes, @button nodes, @chapters, etc. etc. etc.

I consider these to be me telling Leo things.
@persistent seems to be Leo talking to itself.

There is no real
> alternative: it would be a nightmare to store persistence data as uAs,
> for several reasons:
>
> - The data would not be human readable.

- what is the reason for human readable? it's unclear what a human
can use the @persistent tree for other than to break things.

> - The code would have to treat persistence uAs differently from normal uAs.

Don't understand that one.

>
> The Leonine way is to use uA's only for special purposes. It would be
> quite wrong, imo, to use uAs as hidden notes or to contain most other
> valuable data. Almost by definition, valuable data should be
> contained in visible nodes. Yes, there could be exceptions, but they
> truly *are* exceptions.
>
> Edward
>

[Edward K. Ream]

On Wed, Jul 16, 2014 at 12:01 PM, Kent Tenney <kte...@gmail.com> wrote:

> @persistent seems to be Leo talking to itself.

Hehe. Well, almost all data in Leo is in a node. The only exceptions are uA's.

> - what is the reason for human readable? it's unclear what a human
> can use the @persistent tree for other than to break things.

The associations of gnxs with unls could be quite useful.

>> - The code would have to treat persistence uAs differently from normal uAs.
>
> Don't understand that one.

The only other place for data, besides nodes, is in uA's. But the
purpose of persistence is to persist uA's. If we use uA's for
persistence, Leo would have to treat some uA's differently from
others. Trust me, we don't want to go there.

Bottom line. If uA's are considered valuable enough to warrant error
recovery, then they must be out in the open for people to see. I see
no more danger in @persistence trees than in any other kind of tree.
If you want to screw up your data, Leo can't really stop you :-)

EKR

[Edward K. Ream]

On Wednesday, July 16, 2014 9:22:03 AM UTC-5, Edward K. Ream wrote:

> I do notice that the icon box has a black border, indicating that the @auto node is dirty.  That's a recent problem.  I'll fix it asap.

This looks like an interaction problem with the bookmarks.py plugin.  Not exactly sure it's fair to blame the plugin...

Restoring an icon from a persisted uA has the unwanted side effect of setting the @auto file dirty.  I spent some time tracking down this bug, but have no good idea about how to squash it.  Terry, do you have any ideas?

Edward

[Terry Brown]

On Wed, 16 Jul 2014 11:41:37 -0700 (PDT)

"Edward K. Ream" <edre...@gmail.com> wrote:

>
>

You mean todo.py, not bookmarks.py, right? It's tricky, the file
should definitely be marked dirty when the user manually changes the
todo status. It probably shouldn't be marked dirty when the todo uAs
change during load (this happens with the due date icon, which is
updated to future / today / overdue during load). It probably should
be marked dirty when things change programatically (i.e. not manually)
at times other than during load.

Is there something todo.py can call to see if Leo's currently loading
the commander it's in, so not startup in general but loading
specifically for this c? If not, todoController could maybe use hooks
to get that info. itself, i.e. a .mark_dirty() method that uses an
ivar which is initially false (don't mark dirty) but changes to true on
`open2` hook perhaps, provided it's called late enough.

Cheers -Terry

[Edward K. Ream]

On Wed, Jul 16, 2014 at 9:14 AM, Edward K. Ream <edre...@gmail.com> wrote:

> I just upped code that starts to support @recovery trees in each per-file @data tree:

Rev 9a082a8... fixes several problems. All tests pass, including some
by-hand tests of real-world scenarios.

The only remaining items with this project are clearing the dirty
marker and adding a clean-persistence command.

Edward