the problem with UNLs is they don't allow choices which involve
changing the headline. If I change the name of a method, I don't
want to lose the choices for the implementation of that method.
Thanks for doing the work re: gnx setting. The code you provided
works a champ.
The idea would be a table in the companion db which, on closing
the Leo file would generate key/value pairs @auto tree UNL / gnx
on opening the Leo file and after parsing the @auto file, the
@auto tree gnx's would be reverted to the previous ones, simulating
the persistence of regular nodes. No collision issues.
Come to think of it, the table in the companion db could also trivially
save the ua of the @auto tree nodes, ... at which point the @auto
tree nodes are as rich a data store as a regular node.
If the file had been edited outside Leo since Leo saw it last, the nodes
in the db could be tagged as obsolete, or new records created accordingly.
If the db were updated on changes instead of on closing, less would be
lost in a crash.
I'll ruminate this approach until the reason it won't work rears it's ugly.
[-:
On Thu, Jul 3, 2014 at 8:50 PM, 'Terry Brown' via leo-editor
<leo-editor@googlegroups.com> wrote:
> On Thu, 3 Jul 2014 18:30:32 -0500
> Kent Tenney <kten...@gmail.com> wrote:
>
>> p.gnx is not currently writable, would it be a big
>> deal to make it writeable? If not globally, for
>> @auto tree nodes?
>
> So wow, p.v.gnx is a property which only supports get, which is why you
> can't write to it, which wasn't a surprise. What is a surprise to me,
> it's not just returning a hidden variable, it's calling
> g.app.nodeIndices.toString(v.fileIndex), where v.fileIndex
> is a tuple like ('tbrown', '20140703203404', 26811)
> i.e. username, start of session timestamp, count of gnxs created in
> session.
>
> So it looks like making it writeable would be a big deal. Although
> g.app.nodeIndices.toString() shouldn't take long to execute, I do
> wonder how much total CPU time it takes, given how often it must be
> called. Well, having said that, maybe it's not called that much.
> Other than serialization, you're usually dealing with in memory objects
> directly.
>
> Still, interesting I'd never looked at such a fundamental piece of Leo.
>
> Kent - you could write to it like this:
>
> p.v.fileIndex = (p.v.fileIndex[0], my_info, p.v.fileIndex[2])
> my_info = p.v.fileIndex[1]
>
> although that trashes the timestamp and jeopardizes the uniqueness.
>
> I think you should aim to use UNLs instead, seeing they can easily
> persist in @auto etc.
>
> Cheers -Terry
>
>
>> Thanks,
>> Kent
>>
>> On Thu, Jul 3, 2014 at 7:46 AM, Edward K. Ream <edream...@gmail.com>
>> wrote:
>> > On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney <kten...@gmail.com>
>> > wrote:
>> >> The version I'm developing on is using a back end with a bunch of
>> >> dependencies, but I'll see about simplifying it, Sqlalchemy +
>> >> sqlite should be sufficient. (someone with sql chops could
>> >> eliminate sqlalchemy)
>> >>
>> >> Dang, I've been testing choices development with regular nodes,
>> >> but day to day I'm always working in <@auto somefile.py> trees,
>> >> and gnx is ephemeral. Maybe a hash of UNL would work for primary
>> >> key instead of gnx
>> > ...
>> >
>> > Interesting coincidence of several recent trains of thought:
>> >
>> > 1. Recently I removed almost all clones from leoProjects.txt and
>> > leoNotes.txt. You could call it a matter of housekeeping, but I'm
>> > moving towards a workflow in which clones exist only until a project
>> > is done. So they are becoming more ephemeral.
>> >
>> > 2. ArmageDOOM mentioned this link on #leo:
>> > https://news.ycombinator.com/item?id=7511979
>> >
>> > One of the comments was that Leo's file format "hadn't taken off".
>> > Without gnx's, Leo's external files would be identical (or nearly
>> > so) with org mode. No, this doesn't really make @auto processing
>> > any easier, because even org mode sentinels will be unacceptable to
>> > most non-Leonine users.
>> >
>> > 3. I recently realized that clones are a bit of a nuisance for
>> > find/change. The more clones I have, the more duplicates there are
>> > when using F3 (find-next)
>> >
>> > For all these reasons, I am beginning to wonder whether clones can
>> > somehow be put a little more behind the scenes.
>> >
>> > To be sure, clones (vnodes) are likely always to exist as a basic
>> > capability, but if clones can be made just slightly more "ephemeral"
>> > then gnx's might not be needed in external files. For example, I
>> > wonder whether my work flow could be based on a combination of
>> > Terry's bookmarks and (perhaps) automatically generated (and thus
>> > more ephemeral) clones.
>> >
>> > In this context, your comments about hashing the UNL fits right into
>> > the zeitgeist. Bookmarks are, iirc, just unl's...
>> >
>> > In short, this could be an important new direction for Leo. No, we
>> > aren't going to get rid of clones. No, we aren't going to get rid
>> > of sentinels. But there might be important benefits if we can
>> > convert sentinels to org-mode format, and if we can make clones
>> > more of the plumbing than the porcelain (to use git terminology).
>> >
>> > In short, it looks like you are leading the way again, Kent.
>> >
>> > 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+unsubscr...@googlegroups.com. To post to this group,
>> > send email to leo-editor@googlegroups.com. Visit this group at
>> > http://groups.google.com/group/leo-editor. For more options, visit
>> > https://groups.google.com/d/optout.
>>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to leo-editor@googlegroups.com.
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
