That's why i propose we should use single running index in the file, without timestamp or username. That won't survive bzr merge, but neither will your table scheme.
I propose using 2 running indices separated by dot, making gnx look like ab.cd. Cd can be running index unique inside ab, how ab is derived is anyone's guess so far. Without merge problem, running index would be enough. -- Sent from my Nokia N900 ----- Original message ----- > > On Jun 20, 1:03 am, "Ville M. Vainio" <[email protected]> wrote: > > > Why do we need sentinel table in the first place? Why not just use the > > short sentinels (base64 counter) and be done with it? > > Because short gnx's don't work. Leo's present sentinels have the form > id.t.n, where id is a supposedly unique identifier (like a bzr id), t > is a timestamp, and n is a disambiguating index used when gnx's would > otherwise have the same timestamp. Converting this to a base-64 > number will not, in fact, result in a significantly smaller > representation, because the space of numbers to be "covered" is very > large. > > In contrast, with the leo-editor-data line, we need only cover the N > nodes in the external file. Thus, one-or-two-character indices > suffice. > > For reference, here is my present thinking about what an external file > will look like: > > #...@+leo-ver=5-thin > #...@leo-data <list of gnx's> > #...@node 1 * @thin sentinels_test.py > #@@ > # This is a doc part. > #...@c > > #...@+<< a >> > #...@+node 2 ** << a >> > a > #...@-<< a >> > > #...@+others > #...@node 3 *** a-1 > a-1 > #...@node 4 *** a-2 > a-2 > #...@-others > > b > > #...@+others > #...@node 5 ** 1-1 > 1-1 > #...@node 6 *** 2-1 > 2-1 > #...@node 7 **** 3-1 > 3-1 > #...@node 8 ** 1-2 > 1-2 > #...@-others > > Notes: > > 1. Some further comments about node sentinel lines. The form of the > line is: > > #...@node <index> <level> <headline> > > For example: > > #...@node 7 **** 3-1 > > I think this is about as good as can be. The node number is necessary > to resolve clones. The level indicator is the clearest possible > representation *for humans*. The headline is real data, and is always > a useful comment. We could abbreviate @node to, say, @!, but imo @node > is much easier for humans to understand. > > 2. The example does not use the ';/:' convention to indicate that the > body text of a node does not end in a newline. I'm not sure whether > this is a feature or a bug. Either way, whitespace clearly delimits > the <index> and <level> fields from the <headline> field. > > 3. As before, @others and section references have terminating > sentinels. This is required because those constructs embed the > contents of nodes in the body text of another node. > > Edward > > -- > You received this message because you are subscribed to the Google > Groups "leo-editor" group. To post to this group, send email to > [email protected]. To unsubscribe from this group, send email > to [email protected]. For more options, visit this > group at http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
