On Wed, Oct 22, 2014 at 6:35 PM, 'Terry Brown' via leo-editor
wrote:
> 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.
Gnx's would be important even without clones: the
On Fri, Oct 24, 2014 at 3:00 PM, Todd Mars wrote:
> The fact that GNX is considered visually intrusive is a separate issue.
No, it's not. gnx's are visible in sentinel comments, and they must
be stored internally in exactly the same form.
> My diagnosis: you are confusing two diseases as havin
OK great:
The fact that GNX is considered visually intrusive is a separate issue.
There should be a design to mitigate that.
My diagnosis: you are confusing two diseases as having the same cause.
1- There are bad GNX (functionality). If GNX is fixed it makes the visual
worse.
2- There are visual p
On Thu, Oct 23, 2014 at 3:59 PM, Fidel N wrote:
> Couldn't two gnx be stored?
> - a short one visually acceptable for inside the documents that the external
> user will see, just with a reference to the actual gnx it refers to. Maybe
> just an index of the place that the real gnx has within the L
Couldn't two gnx be stored?
- a short one visually acceptable for inside the documents that the
external user will see, just with a refference to the actual gnx it refers
to. Maybe just an index of the place that the real gnx has within the Leo
document.
- A second one, embedded in the Leo file, st
On Thu, Oct 23, 2014 at 12:59 PM, Todd Mars wrote:
> Why not just append a big enough range random number to the end of the
> timestamp...
Because gnx's appear in external files and people already think they
are visually intrusive.
EKR
--
You received this message because you are subscribed t
>
> I'm sorry to jump in like this after long study of the problem by others,
> not me.
>
Why not just append a big enough range random number to the end of the
timestamp, (a different field) so that the gnx starts off with a unique
value, the random part of big enough range that probability of
On Wed, Oct 22, 2014 at 9:44 PM, Matt Wilkie wrote:
>
> if gnx == md5 sum or similar, there is no issue and no data loss possible.
> Identical gnx means identical content, period.
We aren't interested in content, but identity. The gnx is supposed to
be unique and immutable.
Edward
--
You rece
On Wed, Oct 22, 2014 at 7:44 PM, Matt Wilkie wrote:
> Identical gnx means identical content
... belatedly realized this would mean a gnx changes with every single
character entered, so, no, not useful. Sorry for the noise. (I do like
the idea of a program automatically creating clones, or mor
On Wed, Oct 22, 2014 at 4:35 PM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:
> Sure that doesn't trouble Leo at all, but if the
> body contents differ, well, one of them will be lost.
>
if gnx == md5 sum or similar, there is no issue and no data loss possible.
Identical gn
On Wed, 22 Oct 2014 18:34:45 -0500
"Edward K. Ream" wrote:
> On Wed, Oct 22, 2014 at 5:51 PM, SegundoBob
> wrote:
So - does the fact that Edward and my responses to Bob "clashed"
time wise (i.e. were made in parallel not sequentially) illustrate the
problem :-) I guess not :)
Cheers -Terry
>
On Wed, 22 Oct 2014 15:51:28 -0700 (PDT)
SegundoBob 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
> > > wrote:
> > >
> >
> > > Also take the opportunity to switch to a current time, r
On Wed, Oct 22, 2014 at 5:51 PM, SegundoBob wrote:
> 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."
Having the gnx reflect the actual creation time o
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
> > wrote:
> >
>
> > Also take the opportunity to switch to a current time, rather than
> > session start time, timestamp, that would be nice.
>
> It's on
On Wednesday, October 22, 2014 10:24:11 AM UTC-5, Terry Brown wrote:
>
>
> Just seen: http://en.wikipedia.org/wiki/MAC_address#Spying
>
Just retweeted it.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and st
On Wed, Oct 22, 2014 at 10:12 AM, 'Terry Brown' via leo-editor
wrote:
>
> TL;DR: re-instate Bob's timestamp fix in core, doesn't make sense to be
> an off-by-default plug-in. UUID gnxs: wishlist priority, current time
> vs. session start time timestamps would be nice though.
Thanks for this summ
On Wed, 22 Oct 2014 10:12:19 -0500
"'Terry Brown' via leo-editor" wrote:
> I'm still not sure exposing people's network addresses in Leo files is
> ideal
Just seen: http://en.wikipedia.org/wiki/MAC_address#Spying
Cheers -Terry
--
You received this message because you are subscribed to the Goo
TL;DR: re-instate Bob's timestamp fix in core, doesn't make sense to be
an off-by-default plug-in. UUID gnxs: wishlist priority, current time
vs. session start time timestamps would be nice though.
On Wed, 22 Oct 2014 08:46:32 -0500
"Edward K. Ream" wrote:
[snip]
> The fundamental problem is t
in leoAtFile.py
new_auto = False
On Wed, Oct 22, 2014 at 8:51 AM, Edward K. Ream wrote:
> On Wed, Oct 22, 2014 at 7:03 AM, Kent Tenney wrote:
>> I must admit I'm not using new-auto, embarrassing after all my fussing.
>
> I forget: how did you disable it?
>
>> - the @persistence tree got huge, cl
On Wed, Oct 22, 2014 at 7:03 AM, Kent Tenney wrote:
> I must admit I'm not using new-auto, embarrassing after all my fussing.
I forget: how did you disable it?
> - the @persistence tree got huge, cluttered versioning
Interesting.
> The back end db uses gnx for native nodes, concats the headlin
On Tue, Oct 21, 2014 at 8:27 PM, 'Terry Brown' via leo-editor
> I don't understand the above - I don't see how there's more
> than one invocation involved. I certainly thought of the possibility
> of Leo needing to allocate gnxs before all the @auto nodes were loaded,
> if I didn't mention it, an
I must admit I'm not using new-auto, embarrassing after all my fussing.
- the @persistence tree got huge, cluttered versioning
- turned out my back end storage needed to implement it's own keys for
@auto nodes
- if I have @auto myfile.py in multiple Leo files, they need the same keys
The back end
On Tue, 21 Oct 2014 17:29:08 -0700 (PDT)
"Edward K. Ream" wrote:
> My first thought was to delay the allocation of new gnx's until after
> the postpass. Like this:
>
> 1. ni.getNewIndex would allocate None as the gnx if it is called
> before the post-pass. In that case, getNewIndex would add th
Terry congratulated me on fixing #76 erroneous clone markers in @auto
trees. The celebrations are premature.
It's easy to see at least one flaw in the present gnx allocation code: the
post-pass calculates ni.lastIndex after reading all external files
**including @auto nodes**.
But suppose the
24 matches
Mail list logo
