Those are all valid points. In fairness, I think this could be a separate _option_ without affecting existing documents but I see your point. FWIW, in the database world it's generally best not to expose primary keys, so you'd have both an internal id and a public one which would be mapped. Alternatively, a few languages let you specify #region tags that work specifically for folding so that could work too (someday).
I understand this would be a major change to Leo though are that there are higher priority things to do, just thought I'd mention it anyway for future reference :-) Thanks. On Tuesday, August 18, 2020 at 8:35:39 AM UTC-4 Edward K. Ream wrote: > On Mon, Aug 17, 2020 at 6:29 PM <[email protected]> wrote: > > > maybe *someday* a GUID/UUID or a Hash of that gnx > > Let me be clear. I would vote against this proposal, for the following > reasons: > > 1. user-id + timestamp is useful information. Imo, a distinct user id, say > the user's github id, is required to ensure unique gnx's. There has been a > long, technical, discussion of this. > > 2. Any change to gnx format would amount to a change in supported external > files. Any such change would make it impossible for old versions of Leo to > read @file nodes. This is a big deal. > > In short, the supposed advantages, such as they are, do not come close to > justifying a big change to Leo. > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/a93735d4-fee0-4c7e-93ea-8dd547dcfd86n%40googlegroups.com.
