as simple as that routine is, it's too complex for me to
remember and apply consistently. I would rather spend
many many hours coming up with a way to avoid those
5 seconds of effort.
On Fri, Jul 4, 2014 at 2:38 PM, 'Terry Brown' via leo-editor
<leo-editor@googlegroups.com> wrote:
> On Fri, 4 Jul 2014 11:03:08 -0500
> Kent Tenney <kten...@gmail.com> wrote:
>
>> >@shadow has persistent uas and gnxs.
>>
>> and done in an interesting way: the @shadow <file>
>> organizer node ua contains the gnx of the file.
>>
>> @shadow doesn't parse .py, so it doesn't meet my needs
>
> Hmm, I often load files in Leo using the leoserver script to load them
> from the command line, which pulls them in as @edit nodes. The if it
> was a python file and I want it parsed, I just change 'edit' to 'auto'
> and use "refresh from disk". There are some issues with refresh from
> disk but it works in this context. Longwinded way of saying you could
> use @auto to load and parse the file and the switch it to @shadow.
>
> But if there isn't one already, we should have a command that performs
> "@auto" parsing on the selected node. It could also be used if you
> write a bunch of little stub function definitions in one node and then
> want them parsed into separate nodes for easy navigation.
>
> Cheers -Terry
>
>> Could the @auto <file> organizer ua be convinced to persist the
>> gnx's of the last parsed file?
>>
>> ... and, thanks for the reminder, I'll see if c.db will be sufficient
>>
>>
>>
>> On Fri, Jul 4, 2014 at 10:00 AM, 'Terry Brown' via leo-editor
>> <leo-editor@googlegroups.com> wrote:
>> > On Fri, 4 Jul 2014 07:32:19 -0500
>> > Kent Tenney <kten...@gmail.com> wrote:
>> >
>> >> 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.
>> >
>> > As long as you don't go from
>> >
>> > Node A ('ktenney', '20110117134522', 7)
>> > Node B ('ktenney', '20140807232334', 7)
>> >
>> > to
>> >
>> > Node A ('ktenney', 'init_vars', 7)
>> > Node B ('ktenney', 'init_vars', 7)
>> >
>> > or something like that.
>> >
>> > Also changing gnxs might break pointers to nodes from other places.
>> >
>> > You could just
>> >
>> > p.v.u.setdefault('space_vers', {})['id'] = uuid.uuid4()
>> >
>> > or more readable
>> >
>> > if 'space_vers' not in p.v.u:
>> > p.v.u['space_vers'] = {}
>> > p.v.u['space_vers']['id'] = uuid.uuid4()
>> >
>> > using the space_vers `namespace` assuming you'll want to store more
>> > than one thing on the node. Like the index of the version you're
>> > currently viewing, I guess.
>> >
>> > Oh, doh, but that's not helping at all with the @auto stuff.
>> >
>> >> 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.
>> >
>> > And doh again, really should have read the whole email before I
>> > started replying :-}
>> >
>> > Sounds like you're on a reasonable path.
>> >
>> > @shadow has persistent uas and gnxs.
>> >
>> > Cheers -Terry
>> >
>> >> 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 @shadow doesn't
>> >> >> > parse .py, so it doesn't meet my needs
>
> Could the @auto <file> organizer ua be convinced to persist the
> gnx's of the last parsed file?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.
>>
>
> --
> 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.
