Re: Documentation on new data model for Leo outlines

Thanks for all your comments and suggestions. I agree that using integers to access the elements of attrs list is not very readable. There will be time to discuss it further when whole model is settled down a bit. It is still evolving, so I haven't seen much point in polishing it yet. Today, I

ebba40fdb adds explicit keypad bindings to leoSettings.leo

The alternative would be to add code to Leo's core which would default to the non-keypad bindings. However, I prefer the present approach: it more explicitly shows the bindings, and invites users to bind keypad bindings to other commands. The previous rev also makes Numpad and Num_pad

Re: Documentation on new data model for Leo outlines

On Tuesday, May 15, 2018 at 6:36:15 AM UTC-5, Edward K. Ream wrote: all existing Position methods and generators must have exactly the same > *effect* as before. Many (All?) Position methods and generators will > need to be rewritten. That's fine. The new code will be simpler than the > old

Re: Mindmap-like calculations in outline

On Tue, May 15, 2018 at 11:52 AM, Luka wrote: > Is it possible to perform tree-based calculations like in freeplane, > mindjet mindmanager etc? > ​The answer to all such questions must be "yes", because Leo's scripting capabilities are completely general.​ Assume

Re: Documentation on new data model for Leo outlines

On Tue, May 15, 2018 at 8:53 AM, Terry Brown wrote: > > We've discussed this before I think, but returning tuples can be a real > pain for extensibility. ​I agree. I think Vitalije is aware of the trade-offs. For now, I'm happy to let him choose whatever style he likes.

Mindmap-like calculations in outline

Is it possible to perform tree-based calculations like in freeplane, mindjet mindmanager etc? Assume every node has named atrributes (like in valuespace, or some v.u dictionary). Like task duration for project management. I want parent to accumulate sum of all children attributes values:

Re: Documentation on new data model for Leo outlines

On Tue, 15 May 2018 08:04:21 -0500 "Edward K. Ream" wrote: > On Tue, May 15, 2018 at 6:55 AM, Terry Brown > wrote: > > > What about a namedtuple? > > ​That or a bunch. Just to be clear, ​the code itself may change to > make this moot. Realized

Re: @data abbreviation documentation

Hmm, I still see the old comments. Leo 5.7.3 devel, build 20180509115144, Wed May 9 11:51:44 UTC 2018 Git repo info: branch = devel, commit = 110174b3f8a8 Rob... On Wednesday, May 9, 2018 at 7:15:49 AM UTC-4, Edward K. Ream wrote: > > > > ​Thanks for this. Now in LeoSettings.leo at rev

Re: Documentation on new data model for Leo outlines

On Tue, May 15, 2018 at 6:55 AM, Terry Brown wrote: What about a namedtuple? > ​That or a bunch. Just to be clear, ​the code itself may change to make this moot. Another possibility, which I often favor, is to unpack the tuple in place: item1, item2, ... itemN = aTuple

Re: Global and local @outline-data tree-abbreviations

That's a good idea, Terry. I didn't realize this might impact (and improve) other @data types. I will post the feature request this morning. Rob... On Monday, May 14, 2018 at 5:45:57 PM UTC-4, Terry Brown wrote: > > > > Something you could include in the request... > > There are a few cases

Re: Documentation on new data model for Leo outlines

On Tue, 15 May 2018 04:36:15 -0700 (PDT) "Edward K. Ream" wrote: > *Readability will not affect performance* > > attrs[gnx] is a tuple [h, b, ps, chn, sz[0]]. The components should > be accessed via a bunch, or an enum, say, > > e_h = 0 > e_b = 1 > e_ps = 2 What about a

Re: Documentation on new data model for Leo outlines

On Monday, May 14, 2018 at 9:44:11 AM UTC-5, Edward K. Ream wrote: > > > On Mon, May 14, 2018 at 8:02 AM, vitalije wrote: > >> I have just published first two articles about what I have done so far in >> this mini-project. Here are the links: >> >>1. Leo tree model - new

Re: I love Leo, but... Scrivener and Org-Mode

On Mon, May 14, 2018 at 5:05 PM, Israel Hands wrote: > > I got greedy though and added the line below > > > ​​ > g.execute_shell_commands('"C:\Program Files (x86)\SumatraPDF\SumatraPDF.exe" > latex_test.pdf') > > which works but hangs Leo > ​Use a list of arguments, not a