On Tue, Jul 8, 2014 at 11:24 AM, Kent Tenney wrote:
> This is a very crude proof of concept, lots of room for enhancement.
> Don't get me started.
Haha. The purpose of a prototype *is* to get you started ;-) Keep up
the great work.
EKR
--
You received this message because you are subscribed
1. It is a plugin.
2.
My pattern is like;
type type type
Hmm, what if I changed that loop to a generator?
I want to duplicate the work I've done when I click 'right', and
make the changes I want to evaluate, so I want a copy of the
current state to start from. Clicking R or L brings the next choi
On Tue, Jul 8, 2014 at 8:32 AM, Kent Tenney wrote:
> OK, now make the one-line @button right and @button left
A few comments:
1. You have to execute the script every time you launch leo. The
script installs g.update_choice. Of course, that's just a hack for
prototyping.
2. I have been finding
OK, now make the one-line @button right and @button left
Create a node and put some content, click right, nothing happens
except the log message.
Change the current content
Click left, the original content should reappear
Use cases:
choice 0 is a function,
choice -1 is commentary,
choice -2 is
On Tue, Jul 8, 2014 at 7:50 AM, Edward K. Ream wrote:
>> It may still be the spelling of the URI, it's tricky
The trick was to specify no path at all:
uri = r'sqlite:lndb.sqlite'
Now I got a much more helpful error:
QQQ
ArgumentError: Invalid SQLite URL: sqlite://lndb.sqlite
Valid SQLite
On Tue, Jul 8, 2014 at 6:40 AM, Kent Tenney wrote:
> It may still be the spelling of the URI, it's tricky, especially
> on windows because of the / vs \ stuff.
> You may need lots of backslashes ...
> The 'create_engine' call shouldn't require an existing file:
> On linux, when I used
> 'sqlite://
In my short experience with the backslashes thing, I often got to fix those
problems by either:
import re
re.escape("string_to_escape")
or
string = r"string"
I don't often really understand what's happening, but this stops being a
problem.
--
You received this message because you are subscrib
It may still be the spelling of the URI, it's tricky, especially
on windows because of the / vs \ stuff.
You may need lots of backslashes ...
The 'create_engine' call shouldn't require an existing file:
On linux, when I used
'sqlite:tmp/lndb.sqlite'
it generated the file ...
On Tue, Jul 8, 20
On Tue, Jul 8, 2014 at 6:23 AM, Edward K. Ream wrote:
> uri = 'sqlite:c://users//edreamleo//lndb.sqlite'
>
> Got this error:
[snip]
Added four slashes:
uri = 'sqlite:c://users//edreamleo//lndb.sqlite'
Now I get:
OperationalError: (OperationalError) unable to open database file None None
On Mon, Jul 7, 2014 at 9:54 AM, Kent Tenney wrote:
>>So how do we get to play with this?
>
> https://gist.github.com/ktenney/d474f8034c84c56b74e7
Installed sqlalchemy and ran the script in Leo with
uri = 'sqlite:c://users//edreamleo//lndb.sqlite'
Got this error:
exception executing script
Trac
On Mon, Jul 7, 2014 at 9:59 AM, Kent Tenney wrote:
>> Btw, is there a reason not to use c.db?
>
> I'm sticking with a database for a couple reasons:
> access from outside Leo, debugging and inspection tools,
> flexibility. The postgresql store is network accessible, might
> evolve into some kind o
> Btw, is there a reason not to use c.db?
I'm sticking with a database for a couple reasons:
access from outside Leo, debugging and inspection tools,
flexibility. The postgresql store is network accessible, might
evolve into some kind of collaboration thingy.
On Fri, Jul 4, 2014 at 10:06 AM, Edwa
wrote:
> On Tue, Jul 1, 2014 at 10:09 AM, Kent Tenney wrote:
>> OK, I've written a simple implementation of 'spatial versioning'
> ...
>> The gui element turns out to be not required, in fact, I expect
>> it would be horrible to have tabs for each choice.
>
On Sun, Jul 6, 2014 at 9:19 AM, Fidel N wrote:
> Hehehe, here is the link; Finding a node by the tail of the UNL. Current Leo
> working code has that loging working.
>
> https://github.com/leo-editor/leo-editor/pull/13#issuecomment-37282367
Thanks for that.
> Glad you liked the DB idea, back wh
>
> Oh good. Great minds thinking alike :-) Could you tell me the link
> to that conversation? I only vaguely remember it.
>
Hehehe, here is the link; Finding a node by the tail of the UNL. Current
Leo working code has that loging working.
https://github.com/leo-editor/leo-editor/pull/13#i
On Sunday, July 6, 2014 6:58:46 AM UTC-5, Edward K. Ream wrote:
> > That way a node could be tracked down from its initial point to the
> final
> > current actual situation it is in right now.
>
> Cool idea.
>
> Btw, git claims to be able to track file name renames without actually
> keepi
On Saturday, July 5, 2014 2:59:22 PM UTC-5, Edward K. Ream wrote:
>
>
> The more I think about this, the simpler and clearer the picture becomes:
>
> 1. What I have been calling an "official bookmark" is nothing but a clone
> created using a pattern rather than a gnx. That's the only real
> di
On Sat, Jul 5, 2014 at 4:00 PM, Fidel N wrote:
> Hey Eward!
> That seems very similar to what Terry and I did in our last update for unl's
> and recursiveunlfind function.
Oh good. Great minds thinking alike :-) Could you tell me the link
to that conversation? I only vaguely remember it.
> Jus
Hey Eward!
That seems very similar to what Terry and I did in our last update for
unl's and recursiveunlfind function.
On the way we also added repeated names security (second node with same
name would store its number in the UNL) as you know.
I really want to comment on this issue, I have been
On Saturday, July 5, 2014 8:25:37 AM UTC-5, Edward K. Ream wrote:
> suppose the clone command automatically creates an (official) bookmark
node instead of a clone node inside @auto and @org-mode trees.
The more I think about this, the simpler and clearer the picture becomes:
1. What I have been
On Sat, Jul 5, 2014 at 6:10 AM, Edward K. Ream wrote:
> Here, I'm going to discuss thoughts related to supporting org mode, a file
> format that indicates outline structure without using gnx's.l
Terry, I'll be especially interested in your comments to what follows.
> 6. All the big questions (a
I'm going to give the spatial versioning thread back to Kent :-) His work
is important in its own right.
Here, I'm going to discuss thoughts related to supporting org mode, a file
format that indicates outline structure without using gnx's. You could
call this an Engineerin
On Fri, Jul 4, 2014 at 5:26 PM, Edward K. Ream wrote:
> So instead of thinking of views as being defined by sets of nodes with
> given identities, it would be better (more general) to think of views
> as sets of nodes defined in other ways. Such as:
>
> - Sets of nodes matching patterns patterns
On Fri, Jul 4, 2014 at 12:27 PM, Edward K. Ream wrote:
> I think it would be good to set up a conference call between Kent,
> Terry and myself to discuss this. There are s many questions I'd
> like to ask and ideas to explore.
1. I'm seriously starting to wonder whether clones my be thought
ball-parking 10 times a day, gives me 24 hours of dev time
{-;
On Fri, Jul 4, 2014 at 4:03 PM, 'Terry Brown' via leo-editor
wrote:
> On Fri, 4 Jul 2014 15:36:47 -0500
> Kent Tenney wrote:
>
>> as simple as that routine is, it's too complex for me to
>> remember and apply consistently. I would r
On Fri, 4 Jul 2014 15:36:47 -0500
Kent Tenney wrote:
> 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.
http://xkcd.com/1205/
:-) Cheers -Terry
> On Fri,
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
wrote:
> On Fri, 4 Jul 2014 11:03:08 -0500
> Kent Te
On Fri, 4 Jul 2014 11:03:08 -0500
Kent Tenney wrote:
> >@shadow has persistent uas and gnxs.
>
> and done in an interesting way: the @shadow
> 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 le
On Fri, Jul 4, 2014 at 11:03 AM, Kent Tenney wrote:
>>@shadow has persistent uas and gnxs.
>
> and done in an interesting way: the @shadow
> organizer node ua contains the gnx of the file.
>
> @shadow doesn't parse .py, so it doesn't meet my needs
>
> Could the @auto organizer ua be convinced to
>@shadow has persistent uas and gnxs.
and done in an interesting way: the @shadow
organizer node ua contains the gnx of the file.
@shadow doesn't parse .py, so it doesn't meet my needs
Could the @auto organizer ua be convinced to persist the
gnx's of the last parsed file?
... and, thanks for
On Fri, Jul 4, 2014 at 7:32 AM, Kent Tenney 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.
Yes. It's a big problem.
> Thanks for doing t
On Thu, Jul 3, 2014 at 8:50 PM, 'Terry Brown' via leo-editor
wrote:
> On Thu, 3 Jul 2014 18:30:32 -0500
> Kent Tenney 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
On Fri, 4 Jul 2014 07:32:19 -0500
Kent Tenney 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 settin
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.
The idea would be a tabl
On Thu, 3 Jul 2014 18:30:32 -0500
Kent Tenney 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. Wha
p.gnx is not currently writable, would it be a big
deal to make it writeable? If not globally, for
@auto tree nodes?
Thanks,
Kent
On Thu, Jul 3, 2014 at 7:46 AM, Edward K. Ream wrote:
> On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney wrote:
>> The version I'm developing on is using a back end with
On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney 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 ch
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 ...
On Wed, Jul 2, 2014 at 10:32 AM, Edward K. Ream wrote:
> On Tue, Jul 1, 2014 at 10:09 AM, Kent Tenney wrote:
>> OK, I've wri
On Tue, Jul 1, 2014 at 10:09 AM, Kent Tenney wrote:
> OK, I've written a simple implementation of 'spatial versioning'
...
> The gui element turns out to be not required, in fact, I expect
> it would be horrible to have tabs for each choice.
>
> I have 2 buttons: &#
OK, I've written a simple implementation of 'spatial versioning'
A database maintains a table 'choices' with 3 columns:
- id (node gnx)
- index (currently selected choice)
- data (a json dict with numeric keys, the value a dict {'h':p.h, 'b':p.b})
The
On Mon, Apr 28, 2014 at 9:16 AM, 'Terry Brown
' via leo-editor
wrote:
> On Mon, 28 Apr 2014 06:43:45 -0500
> Kent Tenney wrote:
>
>> Standard version control is time-based, my workmethods seem
>> to want space-based versioning, IE: the variations I'm considering
>> are next to each other, not bef
On Mon, 28 Apr 2014 06:43:45 -0500
Kent Tenney wrote:
> Standard version control is time-based, my workmethods seem
> to want space-based versioning, IE: the variations I'm considering
> are next to each other, not before and after.
>
> What would suit me would be a tabbed editor pane. A node wo
On Mon, Apr 28, 2014 at 7:37 AM, Jacob Peck wrote:
>
> On 4/28/2014 8:33 AM, Kent Tenney wrote:
>>
>> Correction: only bodies, not headlines would be versionable,
>> the UNL should stay put.
>
> Agreed. But the tabs would still need titles
Maybe tab titles could be orthogonal to git tags, with gi
On 4/28/2014 8:33 AM, Kent Tenney wrote:
Correction: only bodies, not headlines would be versionable,
the UNL should stay put.
Agreed. But the tabs would still need titles -- so, 'subheadlines',
perhaps? I think these should be editable, but very 'unimportant' in
terms of Leo's API -- second
Correction: only bodies, not headlines would be versionable,
the UNL should stay put.
On Mon, Apr 28, 2014 at 6:43 AM, Kent Tenney wrote:
> Standard version control is time-based, my workmethods seem
> to want space-based versioning, IE: the variations I'm considering
> are next to each other, no
+1, sounds very useful :)
-->Jake
On 4/28/2014 7:43 AM, Kent Tenney wrote:
Standard version control is time-based, my workmethods seem
to want space-based versioning, IE: the variations I'm considering
are next to each other, not before and after.
What would suit me would be a tabbed editor pa
Standard version control is time-based, my workmethods seem
to want space-based versioning, IE: the variations I'm considering
are next to each other, not before and after.
What would suit me would be a tabbed editor pane. A node would
offer the capability to create new versions of it's headline a
47 matches
Mail list logo
