Blog post about valuespace up on leo-editor.github.io

[Ville M. Vainio]

This one is not "exhaustive", but in the interest of time management, I decided to push it as is. I'll blog about more features later on.

http://leo-editor.github.io/valuespace-intro.html

Hope it already helps alleviate the mystery of what it's all about :)

[Matt Wilkie]

Thank you so much Ville.

That looks awesomely powerful. And I have a use for the json slurper right now! I can't wait to try it out.

-matt

--
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+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[HaveF]

Thanks!

Although it beyond my current requirements, maybe, 

I need to read valuespace_example.leo to find more typical usage.

[gatesphere]

Looks really interesting, Ville!  Thanks for sharing, looking forward to diving in.

I'm thinking of some uses for in a rulebook and a few blog posts I'm writing right now.  Being able to have my document be executable seems awesome.

-->Jake

On Tuesday, May 14, 2013 4:15:12 AM UTC+8, Ville M. Vainio wrote:

This one is not "exhaustive", but in the interest of time management, I decided to push it as is. I'll blog about more features later on.

http://leo-editor.github.io/valuespace-intro.html

Hope it already helps alleviate the mystery of what it's all about :)

--

[Edward K. Ream]

On Mon, May 13, 2013 at 3:15 PM, Ville M. Vainio <viva...@gmail.com> wrote:

This one is not "exhaustive", but in the interest of time management, I decided to push it as is. I'll blog about more features later on.

http://leo-editor.github.io/valuespace-intro.html

Thanks Ville, I'll look at it in detail later today.

Edward

[wgw]

Great addition to Leo. 

It brings me back to the idea that the main limitation to Leo is that it isn't a spreadsheet. Spreadsheets have the original clones on steroids, which is part of the power of Leo. Value space inches Leo in the direction of spreadsheets, as you point out in your blog. A leap in that direction would be to put a spreadsheet in Leo's body, or even simply bridge Leo to a spreadsheet. One daydream was to bridge Leo to a Google spreadsheet, but it might be simpler to use python directly : http://manns.github.io/pyspread/ The debian package doesn't work on my setup (Ubuntu 12.04 -- dependency issues), and the dependencies would have to be chopped out, but it looks promising. I picture it appearing in a body window, but that might be a bit cramped: a bridge designed like the ipython plugin would probably be the most usable configuration. (My 2 cents of blue sky.)

[Terry Brown]

On Mon, 13 May 2013 23:15:12 +0300

"Ville M. Vainio" <viva...@gmail.com> wrote:

Yes, thanks. I tried commenting on Disqus, not sure if it save though.

is the @a thing needed - doe's it really take too long to scan the whole
text of every body for @x? I just added some unique text to the end of
LeoPythonRef.leo and searched for it, and it takes less than a second,
so it seems the time spent looking for @x would be much less than the
other processing time.

How about in-body @r ...

and as these results show:

@r res1, res2 {
<content from vs-update here>
}

so the bottom line is

@r res3 {
<content from vs-update here>
}

?

Cheers -Terry

[Ville M. Vainio]

Answered the first one on Disqus already.

You are probably right on not needing the @a. I was thinking of optimizing for huge outlines (with e.g. big logfiles in the tree), but in practice the computation done in nodes (I run several external commands in mine) dwarves the time taken to scan the tree.

Regarding in-body @r - I need one myself, so it's definitely coming :-). @r sounds like a logical choice, earlier I was thinking of something that would look more "workbook"-like, e.g. 

1+1::

=> 2

but @r is simpler and more consistent.

i'll implement both in the next iteration of valuespace. 

[Matt Wilkie]

I see your blue-sky, and add some more, a tad wider afield though :)

http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2

The connecting thread is: very interesting things that can be done with a spreadsheet data/interface structure that have (surficially) nothing to do with cells and numbers.

-matt

--

[wgw]

(oops -- lost my message; I will summarize)

Impressive!

The spreadsheet paradigm seems unique, even though it might be usefully classed under the oo paradigm. What is perhaps unique is the aligning of interface items, which can then be modified en masse. SublimeText does that with multiple cursors. But in general it is hard to understand how trees align, since branches are not necessarily uniform. (And SublimeText muffs aligned cursors when indenting is not the same for every cursor.) But oo trees do offer some kind of alignment through property names (and patterns over property names). In an ooLeo, headlines are properties with the body as value. As it is, clones already inherit those "properties". It is not difficult to imagine clones where branches could be flagged as simple copies (rather than cloned) that can be modified and still be part of the clone (that is counter to Leo's design, I know). Clone-update routine would simply skip overridden branches. So ooLeo doesn't seem like that far away (theoretically only! -- practically, a pipe-dream!).

Some more blue sky ... it is spring :).