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

[Israel Hands]

Thanks Edward,

  g.execute_shell_commands('pdflatex latex_test.tex')

Does indeed do the business - my leo file is in the same directory as the 
latex files which maybe makes the path stuff easier. 

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 so I guess I need a Sumatra batch file.  Can I 
execute that with g.execute_shell_commands?

ta

IH



On Sunday, 13 May 2018 21:03:39 UTC+1, Edward K. Ream wrote:
>
>
>
> On Sun, May 13, 2018 at 8:59 AM, Israel Hands  > wrote:
>
>> Thanks Edward - I hadn't used @clean before and that seems to work just 
>> fine. 
>>
>
> ​Good to know.​
>  
>
> Is it possible to undertake the next step and send commands to the OS 
>> command line
>> ​.
>>
>
> ​Yes. There are many ways.  g.execute_shell_commands is a thin wrapper 
> around subprocess.Popen:
>
>g.execute_shell_commands('pdflatex currentfile.tex')
>
> ​
>> Is it possible to view a pdf from within Leo? I use Sumatra which is cool 
>> but thought I better check while on the subject?
>>
>
> ​On my machine I have a .bat file called acrobat that opens Adobe Reader.  
> ​The following opens any .pdf file without hanging Leo:​
>
>
> ​path = ''
> command = 'acrobat %s' % path
> g.execute_shell_commands(command)​
>
> ​Edward​
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

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

[Terry Brown]

On Mon, 14 May 2018 09:34:27 -0700 (PDT)
Rob  wrote:

> I have a quite extensive (and growing) collection of tree
> abbreviations in myLeoSettings.leo. I would like to also have some
> local-only tree abbreviations that are only relevant for specific
> xxx.leo files. For `regular` abbreviations, there's an @data
> global-abbreviations which are suitable for the main settings file
> and also an @data abbreviations that is suitable for local-only files.
> 
> As far as I can tell, there isn't a global version of the tree 
> abbreviations. That would be beneficial to allow for the same
> flexibility as we have for the @data abbreviations. It would be great
> to have the local tree abbreviations *in addition to* the global tree
> abbreviations. If this is feasible and desirable, shall I enter an
> enhancement request on GitHub?

Something you could include in the request...

There are a few cases where we have 

@data global-foo-settings
@data local-foo-settings

or maybe even

@data global-foo-settings
@data local-foo-settings
@data user-foo-settings

Being wary of Vitalije's dreaded FNMW (flexibility no matter what ;-)
let's consider the possibility of syntax like

@data foo @append

or something that extends @data settings rather than replacing them.
Then we don't have to invent names for all the needed levels of config.,
users can just create what they need with the existing lyered config.
loading.

Cheers -Terry



-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Global and local @outline-data tree-abbreviations

[Rob]

I have a quite extensive (and growing) collection of tree abbreviations in 
myLeoSettings.leo. I would like to also have some local-only tree 
abbreviations that are only relevant for specific xxx.leo files. For 
`regular` abbreviations, there's an @data global-abbreviations which are 
suitable for the main settings file and also an @data abbreviations that is 
suitable for local-only files.

As far as I can tell, there isn't a global version of the tree 
abbreviations. That would be beneficial to allow for the same flexibility 
as we have for the @data abbreviations. It would be great to have the local 
tree abbreviations *in addition to* the global tree abbreviations. If this 
is feasible and desirable, shall I enter an enhancement request on GitHub?

Rob...

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: f104f914f scripts.leo contains prototype of new read code

[Edward K. Ream]

On Monday, May 14, 2018 at 8:10:23 AM UTC-5, Edward K. Ream wrote:

Still to do: The code detects @others and section references but does not 
> alter node structure appropriately.
>

I'm happy to say that Vitalije's Tree Model already does more than I 
envisaged with the prototype, and does it better.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Documentation on new data model for Leo outlines

[Edward K. Ream]

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 approach
>
>2. Leo tree model - loading from a file
>
>
> ​This is superb work.  I never dreamed the code could be improved so much.

*From #1*:

"The other thing I would try to achieve is some stability of positions in
tree. If a tree is modified some positions may become invalid, but those
positions that point to the nodes that are still part of the tree should be
valid even after the tree has been changed."

Imo, this is worth quite a bit of work.

*From #2*:

import xml.etree.ElementTree as ET

​This was new in Python 2.5, but I didn't realize that until just now.  I
am all for replacing the super-ugly sax parser.

*Summary*

I haven't studied this in detail, but what I see looks spot on.

I'm glad I did this morning's prototype.  The get_patterns function looks
like a generalization of my python-only code.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: f104f914f scripts.leo contains prototype of new read code

[Edward K. Ream]

On Mon, May 14, 2018 at 8:10 AM, Edward K. Ream  wrote:

> Vitalije has inspired me.  scripts.leo now contains the node "Prototype:
> new read code".
>
> The prototype quickly recognizes all Leo sentinels and nodes using regexs.
>

​BTW, the prototype uses plain tuples rather than g.Bunches.  It the
consumer and producer parts of the code, using tuples is by far the most
concise style. I wouldn't want to use plain tuples if the uses were far
away.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

f104f914f scripts.leo contains prototype of new read code

[Edward K. Ream]

Vitalije has inspired me.  scripts.leo now contains the node "Prototype: 
new read code".

The prototype quickly recognizes all Leo sentinels and nodes using regexs. 
Here are the stats for reading leoAtFile.py.

read:  0.000716 sec chars:  207806
nodes: 0.007898 sec found:  233
lines: 5034, pat_lines: 273 # About the number of sentinel lines

Splitting lines into nodes and detecting sentinels should take the most 
time, less than 0.01 sec for leoAtFile.py.

Still to do: The code detects @others and section references but does not 
alter node structure appropriately. This should take time proportional to 
the number of nodes (~200) rather than the number of characters.

Imo, this already a successful prototype. The ball is in Vitalije's court. 
I'll defer further work until his next report.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scope issues when using lisp-like style

[Terry Brown]

On Mon, 14 May 2018 01:31:57 -0700 (PDT)
vitalije  wrote:

> for a,b,c in helper_1(x, y):
> m,n,r = a, b, c

Think I stumbled on that myself once.  If it was common, it could be

m, n, r = update_from(helper_1(x, y), m, n, r)

where

def update_from(aList, *args): ...

which is still a bit repetitious, but has 'update_from' as a quick
queue as to what's happening.  That assumes the assignments aren't
expensive though - the for loop version is better at doing nothing if
there's nothing to be done I guess.

> After that I plan to make smallest possible gui to show new model in action.

Heh, that answers my question - is the new data model running in
Leo? :-}

Cheers -Terry

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Documentation on new data model for Leo outlines

[vitalije]

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 approach 
   
   2. Leo tree model - loading from a file 
   
   
The code in its current version is here: leo-tree-model.leo 


Code contains both the definition of LeoTreeModel class and test script 
that will load LeoPyRef.leo and its files, make some profiling tests.

This is still work in progress. I plan to make minimal gui to test and 
demonstrate new model in action.

All comments are welcome.
Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scope issues when using lisp-like style

[Edward K. Ream]

On Monday, May 14, 2018 at 6:05:53 AM UTC-5, Edward K. Ream wrote:

We could also use string.translate 
>  (python 
> 2) or string.maketrans 
>  
> (python 3) to convert sentinels into their equivalents in body text. 
>

Alas, not.  The tables contain only characters.  So we would likely use 
re.finditer to find candidate replacements. How we actually make those 
replacements will depend on the details of the code.

It will be interesting to compare my present ideas with Vitalije's.  A 
prototype might be only a page or so of code, so I might not be able to 
resist :-)

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scope issues when using lisp-like style

[Edward K. Ream]

On Monday, May 14, 2018 at 5:54:50 AM UTC-5, Edward K. Ream wrote:

​
>  ​Leo's read/write code is a transliteration of ancient C code. Using 
> regex's to find sentinels should be much faster, and more pythonic. That's 
> where I would expect the biggest speed improvements.
>

We could also use string.translate 
 (python 2) 
or string.maketrans 
 
(python 3) to convert sentinels into their equivalents in body text. This 
promises another large (C-like) speed improvement.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scope issues when using lisp-like style

[Edward K. Ream]

On Mon, May 14, 2018 at 3:31 AM, vitalije  wrote:

> The so called "*lisp-like style*" is not a silver bullet.
>

​Thanks for this discussion.  As I said earlier, many of Leo's small
commands could profitably use lisp-like style to hide their helpers. That
might even be worth doing now.
​


> When these solutions do not suffice I prefer to have top level list over
> having top level name-space dictionary.
>

​Unless speed is critical, a top-level g.Bunch would likely be better. It's
less clumsy than a namespace dict, and easier to use than a list, because
it uses names instead of indices.


> Accessing local vars is much cheaper then accessing ivars on self.
>

​This speed difference usually isn't important.  But it might yield a good
performance boost in Leo's read/write code.
​

​Leo's read/write code is a transliteration of ancient C code. Using
regex's to find sentinels should be much faster, and more pythonic. That's
where I would expect the biggest speed improvements.

Edward​

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Working on new data model for Leo - preliminary results

[Edward K. Ream]

On Mon, May 14, 2018 at 4:00 AM, vitalije  wrote:

> I am about to continue work on this project. Just to report progress:
>

​Sounds excellent.

Edward

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Working on new data model for Leo - preliminary results

[vitalije]

I am about to continue work on this project. Just to report progress:

LeoTreeModel class now can both read and write Leo files and external files 
with sentinels (@file nodes). Writing all external files in 
leo/core/LeoPyRef.leo on my machine takes about 1400 ms.  Writing all those 
@file nodes using atFileCommands takes about 4500ms.

Currently I am working on documentation trying to explain all that I have 
done so far in this project. 

After that I plan to make smallest possible gui to show new model in action.

Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scope issues when using lisp-like style

[vitalije]

The so called "*lisp-like style*" is not a silver bullet. It carries its 
own problems, one of them is like you have noticed is updating local 
variables in top level function. However, more often than not, it is 
possible to deal with this issue in the following way. Whenever we need a 
helper function that should update top-level local variable, then we can 
return updated value and let top-level function to update variable. For 
example:
def my_top_level_function(x, y, z):
m = 

def helper_1(s, t):
new_m = m
 update new_m
 calculate some result
return result, new_m

def helper_2(a, b):
# helper_2 has nothing interesting to return
# but needs to update m
new_m = m
...
... update new_m
...
return new_m
...
h1_result, m = helper_1(x, y)
...
m = helper_2(y, z)
...


Sometimes a helper function may or may not update several top-level vars. 
In such a case I usually use:
def my_top_level_function(x, y, z):
m = 
n = 
r = 

def helper_1(s, t):
...
if someCondition:
# update m,n,r
yield new_m, new_n, new_r

...
for a,b,c in helper_1(x, y):
m,n,r = a, b, c

...


This will call helper_1 and if it yields anything top-level vars will be 
updated, and if it doesn't yield anything program continues normal 
execution.

When these solutions do not suffice I prefer to have top level list over 
having top level name-space dictionary. For example:
def my_top_level_function(x, y, z):
# variable m need to be updated from several places
m = []

def helper_1(a, b):
_m = m[0]
...
m[0] = _m = ...
...
...

About year ago I have made some experiments in reading and writing external 
files. At first I made two stand-alone read/write functions. Edward or 
someone else suggested that I pack those two functions into classes. I 
remember I have done that and compared that class based solution with 
stand-alone functions. Class based solution was about two times slower. 
Experiments are located in leo-snippets line-numbering.leo 
. It has 
several nodes labeled exp-1, exp-2, ...

In exp-7 is the speed comparison of DerivedFileWriter class  and function 
p_to_text(p, delim_st, delim_en)
On my machine function p_to_text writes leo/core/leoCommands.py on average 
in 69.4ms, and DerivedFileWriter writes the same file on average in 141ms.

Accessing local vars is much cheaper then accessing ivars on self. Local 
vars live on stack which means they are close to one another and most 
likely they are all in CPU cache. Instance ivars OTOH, reside on heap and 
they may be far away from each other, which means CPU may need to 
invalidate cache and fetch them from heap. This explanation is just my 
speculation or the way I understand the problem. I may be very wrong in 
this. But the fact that solutions with functions and local ivars are most 
often faster than class based solutions remains true, even if my 
explanation of "why" is wrong.

HTH Vitalije

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.