On Wed, 22 Oct 2014 15:51:28 -0700 (PDT) SegundoBob <segundo...@gmail.com> wrote:
> > > On Wednesday, October 22, 2014 9:16:55 AM UTC-7, Edward K. Ream wrote: > > > > On Wed, Oct 22, 2014 at 10:12 AM, 'Terry Brown' via leo-editor > > <leo-e...@googlegroups.com <javascript:>> wrote: > > > > > > > > Also take the opportunity to switch to a current time, rather > > > than session start time, timestamp, that would be nice. > > > > It's on the list. It fits in well with coming changes to the > > NodeIndices class. > > > > > I see the appeal of "current time," but making this switch almost > certainly requires losing the benefit of minimizing the node index by > only considering GNX's with the "session start time." The change of > time zone or daylight saving could cause times after the session > start time to equal times in already existing GNX's. The current time would come if you were using uuid.uuid1(), but ironically version 1 UUIDs a aren't really guaranteed unique. They have a timestamp with a specified unit of "100 nanosecond intervals since 00:00:00.00, 15 October 1582". Yes, 1582, the start of the Gregorian calendar, not 1970, the start of the unix epoch. Plus they have 14 random bits, but 2**14 is only 16384, so although the chance of collision would be minuscule, not as minuscule as the content free version 4 uuid, with about 120 random bits, or 2**120 = 1329227995784915872903807060280344576 values. > Or do you want to do a complete scan to determine the minimum unused > node index before every node creation that changes the time stamp? No, I'm sure that would be too slow. > --------- > New Topic: > > Early in this thread, you seemed concerned, once again, about one GNX > being used in two different files. This should not concern you. It > doesn't bother Leo-Editor at all. It does happen all the time. For > example, I just copied a Leo-Editor file and then opened both copies > in one Leo-Editor session. Leo was happy. I was happy. When I > copied a node from copy1 and pasted it into copy2 "retaining clones", > it became a clone in copy2. I was happy. This is what I would > expect. The concern is for the extremely uncommon cases where what you describe happens unexpectedly. Sure that doesn't trouble Leo at all, but if the body contents differ, well, one of them will be lost. To be honest I don't know what the intended behavior / use case for paste-retaining-clone is. I'd assume that pasting a subtree containing, internal to itself, clones, from outline A to outline B, would lose the clones with plain paste, and keep them with paste-retaining. But they're kept in either case. Of course, given the three alternatives to clones Leo has, I /personally/ would be fine with clone free Leo, but I know they're Leo's killer feature for a lot of people. > For your benefit and the benefit of Leo-Editor users, you need to > make this clearer in the Leo-Editor documentation. http://leoeditor.com/commands.html?highlight=retaining#cutting-pasting-and-deleting-nodes The distinction between the top level node in the copied subtree and its children seems confusing, but otherwise I'm not sure if the docs. are complete / sufficient or not. Cheers -Terry -- 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.
