from:"vitalije"

Hello,
I have updated my Leo installation yesterday and bumped in a bug with new 
@nosent code. Most of my files have been kept in @nosent nodes. Whenever I 
open leo file with @nosent nodes, Leo reports Recovered nodes. All those 
nodes are using multiline comments between @ and @c directives. With every 
opening Leo adds single line comments in front of those lines.

I have attached Leo-file which demonstrates the problem.
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


nosent-comment-bug.leo
Description: Binary data

Re: @nosent and multiline comments bug

about my installation: Ubuntu 14.04

** isPython3: False
Leo 5.0-final, build 20150127110559, Tue, Jan 27, 2015 11:05:59 AM
Git repo info: branch = master, commit = f2ca65ecf8e8
Python 2.7.6, PyQt version 4.8.6
linux2

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

@nosent goto line bug

For quite a long time I have noticed that command goto global line (Alt+G) 
doesn't work properly on @nosent files. It seems that it counts 
non-existing sentinel lines so it positions cursor few lines before the 
requested. The exact difference between required line number and found one 
depends on size of file and number of nodes, and also grows with required 
line number.

You can exhibit this by looking in attached Leo file. For example Alt+g 45 
should position cursor on the declaration line of function temp7(a), but it 
positions cursor on line 39.

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


nosent-goto-line-bug.leo
Description: Binary data

Re: @nosent and multiline comments bug



>
> This is a nasty problem.  It's been around since day one of the @shadow 
> algorithm, but it's only been reported now. It will requires some kind of 
> special case for @...@c.  I'll have to think about what is the best way to 
> proceed.
>
> Edward
>

Well, I could live without @ and @c, but it would be useful if Leo delete @ 
and @c lines and replace all those lines with properly language specific 
commented block.
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: @nosent and multiline comments bug



> I am wondering whether it might not be better simply to prohibit @...@c in 
> @nosent files.  How odious would that be for you?
>
> Edward
>
As I said, I could live with such restriction, but it would help if Leo 
change such blocks of code without user intervention. I think that no user 
using @nosent would object this Leo behaviour.

-- 
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

an idea regarding @ and @c directives inside @nosent and @shadow nodes

We have problem with @ and @c directives. For most languages I can think of 
it would suffice if Leo just replace those blocks, along with directives, 
with properly block commented text. But for @rst  files those blocks are 
used for special @rst-options. 

What if Leo before writing Leo-outline replaces those lines with actual 
content they would have in target file, and put some special mark in uA for 
such nodes. When reloading from disk later, Leo would not find those lines 
different from the related lines in body content. After reloading Leo 
should simply walk the whole tree and wherever finds special uA replaces 
commented lines accordingly with block surrounded with @ and @c.

For example if a node that is part of @nosent tree,  with the following 
body, should be written:

@
  Test comment
  another line of comment
@c
def test(n):
print(n)

Leo would immediately before saving outline, replace the content of the 
body with the following:

#  Test comment
#  another line of comment
def test(n):
print(n)
and in uA of the node it would add an attribute 'at-comment-block', 
something like:
p.uA['at-comment-block'] =((0,2),)

Then after loading outline, it would search for 'at-comment-block' 
attribute and wherever it finds it, it would insert '@' and '@c' at 
specified positions, while removing comment delimiter from inside lines.

My 2 cents
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: @nosent goto line bug

2015-02-16 Thread vitalije

I have just filled a bug report

https://github.com/leo-editor/leo-editor/issues/138

-- 
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Any reason to keep @auto or @shadow?

2015-02-20 Thread vitalije



>
> I'll add support for @clean today. Leo 5.1 will come out in a few days.
>
> Edward
>

Please take a look into global-goto-line bug 
<https://github.com/leo-editor/leo-editor/issues/138> before releasing 5.1, 
especially  because it relates to @clean files, and I guess it wont be too 
hard to deal with.

It can be frustrated to new Leo users if they try to find exact line 
reported by some compiler and Leo shows them wrong line.

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Any reason to keep @auto or @shadow?

2015-02-20 Thread vitalije

No, it can't be "frustrated", but it can be frustrating new users.
Sorry, English is not my first language.

>
> 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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: @nosent goto line bug

2015-02-24 Thread vitalije



> Fixed at rev 3ee6afd.  Let me know if you find any further problems.
>
>
I must admit it seemed to me that this bug was fixed, but here is another 
example that demonstrate error in goto-global-line.

In attached Leo file I just put one organizer node and goto-global-line can 
not find any requested line in file.

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.


nosent-goto-line-bug.leo
Description: Binary data

Re: @nosent goto line bug

2015-02-26 Thread vitalije

Again, I have read in another thread: "Leo 5.1 will be soon released". 
Just to bring Edward's attention to this thread and the fact that this bug 
has not been fully fixed yet.
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Watch out! clones get corrupted

Hello
this morning I found one of my Leo files,  that I worked on a few days ago, 
corrupted. While opening the file, Leo hanged and I had to kill it. After 
some examination of xml source I found that some of my last added nodes got 
the same gnx. One of them had child with the same gnx and that caused Leo 
to hang. I have changed manually gnx of the parent node in xml. When I 
finally open outline in Leo I found few other nodes were missing or had 
wrong headline/body.
I don't know what caused this and can't reproduce it but I strongly suspect 
it has something to do with recent changes in Leo write.
Unfortunately I can't say which revision I used to write the problematic 
file. It was one of the revisions after 
934537266cf5d3e556025adc6ba39ff35be81741 
which solved bug #138. This morning I pulled latest Leo revision before 
trying to open file.

I am using Ubuntu 14.04 64bit,
 Leo 5.0-final, build 20150305163031, Thu Mar  5 16:30:31 CST 2015
Git repo info: branch = master, commit = 4dddcc1ac5d8 
Python 2.7.6, PyQt version 4.8.6
linux2 


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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Watch out! clones get corrupted

It happened again. Right now I have the same situation.
Here is the part of a new Leo file that was wrongly saved. I don't recall 
doing anything except deleting few nodes.
31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16 
 vitalije: @clean stylesheets/main.less


31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16  
vitalije: 
31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16  
vitalije: zastavice
31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16  
vitalije: polozaji
31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16  
vitalije: 
31730c1838 <http://localhost:8080/info/31730c1838fe13e3> 2015-03-16  
vitalije: polozaji zastavica
d4a856595b <http://localhost:8080/info/d4a856595bad9616> 2015-03-16  
vitalije: 
d4a856595b <http://localhost:8080/info/d4a856595bad9616> 2015-03-16  
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Travails of a newbie


>
>
>
>> Finally, there is some mysterious key combination that makes the outline 
>> disappear, and makes Leo unresponsive to any further file operation.  This 
>> has happened twice. What is going on with that?  I have to use the Task 
>> Manager to force Leo to close, and lose my updates.
>>
>
> This is the first I have heard of such problems.  I recommend running Leo 
> from a console, as described here: 
> http://leoeditor.com/running.html#running-leo-from-a-console-window
> The console often will tell you when something mysterious happens.
> 
>
>
It could be connected with problem with corrupted node indexes that I wrote 
about in another thread. When some node become child to itself, Leo stops 
responding.
 

-- 
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Watch out! clones get corrupted

I think that methods which manipulate nodes on lowest level should check 
and alarm user if ever node with same gnx is added, inserted, moved,... in 
children (or maybe even in subtree in general).

That way we could easily detect when something goes wrong and save outline 
in different file.
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

goto-global-line doesn't work properly in @clean files

2015-05-30 Thread vitalije

A few months ago I have filled similar bug report against @nosent files.
Well that bug is fixed and Leo properly finds global line in @nosent files.
:-)

OTOH, since then @clean files are introduced and suggested as better
replacement for @nosent files. Well, command goto-global-line can't find
proper line in @clean files. If turned into @nosent file, command
goto-global-line works as advertised.
I pulled newest version of Leo from git this morning and problem is still
there.

Leo Log Window

Leo 5.1-final, build 20150529185559, Fri May 29 18:55:59 CDT 2015

Git repo info: branch = master, commit = 9122fe9233cb

Python 2.7.6, PyQt version 4.8.6
linux2

You can see the problem in example.leo file
<https://11707503125000652521.googlegroups.com/attach/63f325cf79f6b2e9/nosent-goto-line-bug.leo?part=0.1&vt=ANaJVrEFOqs7FjwohsShTGNcPvTY-neL0Bo1HM69Du4ut9S9FNhvRdiBCr5P9xR8iVVp53Mv15nj28FJb7AWRn6WCrWuTp12GR91I-HvbIlypzqXs6SVYh8>

that I send for the former bug report, just turn @nosent test.js into
@clean test.js. Link is here
<https://11707503125000652521.googlegroups.com/attach/63f325cf79f6b2e9/nosent-goto-line-bug.leo?part=0.1&vt=ANaJVrEFOqs7FjwohsShTGNcPvTY-neL0Bo1HM69Du4ut9S9FNhvRdiBCr5P9xR8iVVp53Mv15nj28FJb7AWRn6WCrWuTp12GR91I-HvbIlypzqXs6SVYh8>

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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: goto-global-line doesn't work properly in @clean files

2015-06-02 Thread vitalije

I presume Edward missed this topic, so I am just touching it again.
IMHO this bug can easily repel newbies. If one is not able after seeing 
stack trace in console, to easily find a specific line in source code using 
Leo, he could get very wrong impression about Leo's capabilities. 
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 http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Syntax coloring cloned node

2016-09-27 Thread vitalije


One possible solution would be to use Leo-UNL instead of clones. For 
example in your @rst file you put somewhere following:

.. code:: nasm
LEOUNL:: 

Then run the following script (could be turned in to button) to generate 
your rst files:
@first # -*- coding:utf-8 -*-
import re
import os
LEOUNLpat = re.compile(u'LEOUNL::([^#]*)#(.*)$', re.M)
def process_rst_files():
for p1 in c.allNodes_iter():
if p1.h.startswith(u'@rst '):
fname = p1.h[5:].strip()
g.es(u'processing %s'%fname)
do_one_file(p1, fname)

def do_one_file(p1, fname):
c.rstCommands.processTree(p1, None, toString=True, justOneFile=True)[0]
fname = os.path.join(c.getNodePath(p), fname + '.txt')
s = c.rstCommands.source.decode('utf-8')
s = putLeoCode(s).encode('utf-8')
s1 = getfile(fname)
if s1 != s:
putfile(fname, s)
g.es('changed')
else:
g.es('unchanged')

def getfile(fname):
try:
s = open(fname,'rb').read()
except IOError:
s = ""
return s

def putfile(fname, s):
out = open(fname, 'wb')
out.write(s)
out.close()

def putLeoCode(txt):
i = 0
res = []
while i < len(txt):
m = LEOUNLpat.search(txt, i)
if not m:
res.append(txt[i:])
break
else:
res.append(txt[i:m.start()])
ind = u'\n' + indentation(txt, m.start())
leofile = m.group(1)
unl = m.group(2)
found, depth, p1 = g.recursiveUNLSearch(unl.split(u"-->"), c)
if found:
kod = c.p.b.splitlines(False)
res.append(ind.join(kod))
else:
print (u"Leofile:"+leofile)
print (u"unl:[%s]"%unl)
print (u'not found')
raise ValueError, unl
i = m.end()
return u''.join(res)

def indentation(txt, i):
j = i
while j > 0 and txt[j-1] == ' ':
j -= 1
return ' '*(i-j)
process_rst_files()

I am still using python2. If you use python3 I believe it would complain a 
little about syntax. In that case remove all .encode('utf-8') and 
.decode('utf-8') and all string literals that are prefixed with u should be 
without that prefix.
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.

Re: Leo's real weaknesses

2017-01-13 Thread vitalije


>
> Converting from xml to (say) json, won't help.
>
> IMHO it is not necessarily true. I don't suggest changing Leo document 
format from xml to json or any other format. But there can be found a 
scheme of encoding a Leo document in such a way that its changes can be 
expressed in a human readable diffs. That scheme can be just an additional 
format. Its purpose is not to replace xml. 

First let us analyze what kind of changes can we made by editing any given 
Leo document.

   1. we can edit content of any body, which means a standard plain text 
   changes (adding a line, deleting a line or changing some part of a line). A 
   standard diff tools are good in dealing with those kind of changes.
   2. or we can rearrange nodes. A simple edit such as sorting children of 
   one node, can make a very hard to understand diffs. 
   
A few years ago I tried to combine Leo with fossil <http://fossil-scm.org/>to 
make it possible to see how any particular Leo document evolved. A fossil 
is just one executable file which can be easily incorporated with the Leo 
itself, it doesn't need to be installed or configured to work. 

I have made a script that encodes entire Leo tree into bunch of files one 
per each node named after gnx, and one special file named __LEOTREE__. The 
__LEOTREE__ file contents was just a list of lines that describe 
connections between nodes. Each line started with the level of the node it 
represents followed by its gnx. The node files were encoded with the simple 
scheme. Headline was a first line, followed by the body content of the 
node. The script would generate all those files in a temporary folder and 
then invoke a `fossil commit` there. Fossil would analyze content of the 
folder and record all changes.

The other script I have made would invoke fossil to print a timeline with 
all recorded versions, and offer a user to choose one of them. After user 
makes a choice that particular version would be extracted and content of 
the any given node that existed in that version would be displayed. 

I didn't go any further in developing that idea mostly because I couldn't 
find a good way to show those choices to the user and to show different 
versions of a node. That was before a view rendered plugin appeared, (which 
I still don't use). I guess maybe it could be used to show diffs or 
different versions of a node.
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: Leo's real weaknesses

2017-01-13 Thread vitalije

I suppose it can be done with the git also. But in that case user would 
need to have git installed and also git would need to recreate '.git' 
subfolder inside temporary folder every time. Fossil OTOH, keeps all its 
data in just one file which is in fact just sqlite3 database file. One can 
access its content with sqlite3 python module. Fossil itself is just one 
executable file about 1.5 - 2Mb which can be downloaded by a python script 
if it is not already available in the system path. Fossil executable 
contains also a standalone web server and can communicate and synchronize 
data with remote repositories through HTTP or SSH.

Scripts do not depend that much on fossil. They just run fossil through 
subprocess module. All that is needed to replace fossil with git is to 
change command line arguments. I believe fossil and git have similar 
commands but they use different names. 

If you are interested in those scripts I will try to find (or recreate) and 
share them.
Vitalije

On Friday, January 13, 2017 at 5:31:48 PM UTC+1, Edward K. Ream wrote:
>
> On Fri, Jan 13, 2017 at 4:53 AM, vitalije 
> > wrote:
>
> Converting from xml to (say) json, won't help.
>>>
>> IMHO it is not necessarily true. I don't suggest changing Leo document 
>> format from xml to json or any other format. But there can be found a 
>> scheme of encoding a Leo document in such a way that its changes can be 
>> expressed in a human readable diffs.
>>
>
> This is very interesting.  Do you think your ideas/scripts can be adapted 
> to git?
>
> > I didn't go any further in developing that idea mostly because I 
> couldn't find a good way to show those choices to the user and to show 
> different versions of a node. 
>
> Yes, this a real problem. I'm not sure even perfect, high-level diffs do 
> much good if the user can't use them easily.
>
> 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: Leo's real weaknesses

2017-01-14 Thread vitalije

I couldn't find my earlier works but I have (re)created some script that 
can be used for experiments. In the attachment of this message is 
`fossil-leo.leo` file which contains one @button script.
Before running this script one should provide that fossil executable is 
somewhere in the path. Fossil can be downloaded from fossil-scm.org

The script performs two different actions depending on the switch in its 
root node.
The first action is to create a repository (if it doesn't exist), and then 
to put current content of the Leo outline in the repository. One should 
perform this action several times after making any changes in outline. 
Every time this script is executed new version is added (unless there are 
no changes).

After you create several versions you can change the switch in the root of 
script so that script performs another action. The other action is to 
retrieve content of any given node at the given time. Before performing 
this action one should adjust the arguments of the function call `
fossil_cat_at_time` to reflect his/her own Leo document. Time should be 
after the first version, and the name of file should be existing gnx that 
has been already stored using the first action. Content of the given node 
is presented in the log pane named 'History'. 

If you put the gnx which didn't exist at the given time, script would 
produce an error.

This is just for experimenting. Someone good with the Qt may find a better 
way to show versions and also to allow user to choose particular version. 

function fossil_timeline can be used to retrieve names of the last 20 
versions, or  with some tweaking any other list of versions. Every version 
has canonical name like hexadecimal literal and the time it was committed. 
This list can be parsed and displayed as a list, combo or scale widget 
where user can easily choose version. A gnx can be either a gnx of the 
current position or position that was selected when the widget was 
constructed.
Together gnx and version name (SHA1 hash) can be used by function `
fossil_cat` to retrieve content of the node in specified version.

If this should become a plugin than perhaps it could also check whether 
there is fossil on system path or not and if it is not installed to 
retrieve correct version for the platform and install it somewhere in Leo 
folder and all fossil commands should be adjusted to use the downloaded 
executable.
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.


fossil-leo.leo
Description: Binary data

Re: Leo's real weaknesses

2017-01-14 Thread vitalije

FYI the above script will create a repository in current directory. If you 
execute the following command:

fossil ui leohistory.fossil

(you may need to provide a full path to leohistory.fossil)
it should open your default browser and show you the home page of the 
repository. There you can find timeline, diffs in different formats, 
content of each node, etc.
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: Leo and fossil

2017-01-16 Thread vitalije



On Monday, January 16, 2017 at 11:45:56 AM UTC+1, Edward K. Ream wrote:
>
> So now I am more receptive to these ideas.  
> Edward
>
Glad to hear that.  

-- 
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: Leo and fossil

2017-01-17 Thread vitalije

Database is just a part of fossil. It isn't question of where Leo can keep 
its data. It's about keeping a history of data. Fossil keeps (in efficient 
way) all versions of the data, it can show the diffs in several formats, 
... pretty much all that git does. The advantage of using fossil instead of 
git, IMHO, is that:

   - it doesn't need to be installed (it is just one executable file, 
   available for all platforms that  Leo supports)
   - it keeps all its data in just one file, while git creates .git subtree


On Monday, January 16, 2017 at 5:25:22 PM UTC+1, Terry Brown wrote:
>
> Another question is whether the integration is just at the load/save 
> level or at the node traversal level, i.e. constantly using a data 
> backend.  I think if we started with the load/save level, the sweet 
> spot might be some subtree / node level live refresh from a data 
> backend. 
>
> For diffs, seems an xml to yaml conversion would achieve that?  Like I 
> say, haven't been following the conversation too closely. 
>
> Cheers -Terry 
>
> I don't expect integration to be at node traversal level. At the load/save 
phase (or even on an explicit user request), fossil would record the new 
version of the outline. Later, a user might want to see how and when some 
node has changed, or what was it like in some earlier version. The simple 
script I made for the experiment already enables all that functionality. 
The next more challenging task is to create an elegant GUI that user can 
use to run all those functions.
I haven't programed in PyQt for a long time. Many things I used to know I 
forgot  and there seem to be a lot of changes in PyQt since. Nevertheless, 
I can imagine how GUI might be like. For example, imagine a small slider 
widget along the bottom of body, or in status line, that represents time. 
User can slide it left or right and the selected body would change 
accordingly as it was at the selected moment. When focused slider would 
enable user to switch to the previous/next version using the arrow keys.

I am not sure that all this would be useful at all. I can't recall when was 
the last time that I needed something like this. But maybe I would use it 
more often if it was possible in the first place. The way I see it, this 
can be interpreted as "undo/redo" functionality but persistent between 
editing sessions and spread at node levels, i.e. every node has its own 
"undo/redo" timeline. It may be useful, who knows?

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: Leo and fossil

2017-01-17 Thread vitalije

On Tuesday, January 17, 2017 at 3:19:58 PM UTC+1, Terry Brown wrote:
>
> I assume you mean it's just one Python file, that could be distributed 
> with Leo?  That is an advantage. 
>
> Fossil is native application not python script. 

>
> backend.snapshot_node(, ) 
> backend.node_versions()  # list version_ids of available versions 
> backend.get_node(, ) 
> Cheers -Terry 
>

Well, I can easily change my script to provide API that Terry suggested, 
using fossil.

I'm not sure there's enough difference in convenience there to put a lot 
> of weight on that distinction. 

You are right. It maybe just matter of preference and therefore not so 
important. IMO, sharing, moving, copying is much faster(=easier) for a 
single file than for a subfolder.

As I have seen in links that you pointed to, you have done some node 
versioning before. I didn't study it very thoroughly so I maybe very wrong, 
but I feel that you had some unnecessary difficulties with the UNLs, so you 
encoded them into base64. In my outline encoding scheme, I believe those 
problems are voided. 

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: I've declared war on fit and finish problems :-)

2017-03-29 Thread vitalije



> For example, I recently ignored an apparent problem with Alt-G, 
> goto-global-line.  It would have been best to *stop everything* and make 
> careful notes about how to recreate the problem, but I didn't do that. Now 
> I can't find anything wrong with Alt-G. Live and learn.


I remember posting an example leo file that demonstrates problems with 
goto-global-line. Here is the original post 
https://groups.google.com/forum/#!searchin/ 
<https://groups.google.com/forum/#%21searchin/leo-editor/author$3Ame/leo-editor/zJtp1nkFTZM/tFgWmBqDgfoJ>
leo-editor/author$3Ame/leo-editor/zJtp1nkFTZM/tFgWmBqDgfoJ 
<https://groups.google.com/forum/#%21searchin/leo-editor/author$3Ame/leo-editor/zJtp1nkFTZM/tFgWmBqDgfoJ>

There was attached file 
<https://11707503125000652521.googlegroups.com/attach/63f325cf79f6b2e9/nosent-goto-line-bug.leo?part=0.1&vt=ANaJVrEFOqs7FjwohsShTGNcPvTY-neL0Bo1HM69Du4ut9S9FNhvRdiBCr5P9xR8iVVp53Mv15nj28FJb7AWRn6WCrWuTp12GR91I-HvbIlypzqXs6SVYh8>.
 
I have just updated my Leo and tested this file and once again 
goto-global-line is not working correctly.
AFAIR problems were somehow connected with the presence of the doc parts in 
code.

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.

Possible bug in pluginsController.registerOneHandler

2017-04-05 Thread vitalije



# from leoPlugins.py file

def registerOneHandler(self, tag, fn):

"""Register one handler"""

try:

moduleName = self.loadingModuleNameStack[-1]

except IndexError:

moduleName = ''

...

items = self.handlers.get(tag, [])

if fn not in items:

   bunch = g.Bunch(fn=fn, moduleName=moduleName, tag='handler')

   items.append(bunch)

self.handlers[tag] = items

It looks like the above code checks to see if given function has already 
been registered, (`if fn not in items:`) but then it puts a bunch instance 
in items not the handler function. Unless I am mistaken, it will never be 
the case that the above condition is False, because handler function will 
never be added to items array.
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: Possible bug in pluginsController.registerOneHandler

2017-04-05 Thread vitalije



On Wednesday, April 5, 2017 at 7:24:15 PM UTC+2, Edward K. Ream wrote:
>
> Good catch. The test above looks like mistaken defensive programming. We 
> could eliminate the test entirely, or test each bunch in items:  if 
> bunch.fn == fn:...
>
> Care to change this yourself?
>
> Edward
>

I'll try ASAP (in a day or two).
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: Possible bug in pluginsController.registerOneHandler

2017-04-06 Thread vitalije

I tried to `git push` my corrections but was refused with status 403.

So I forked leo-editor and pushed changes to my fork of leo-editor. I have 
added two new @test nodes in leo/test/unitTest.leo that test expected 
behavior of registerOneHandler and registerOneExclusiveHandler. After that 
I have made some corrections in leo/core/leoPlugins.py to make new tests 
pass. 

However, when I tried to run all unit tests to check that I didn't broke 
something else in Leo codebase, I've got more than 100 failed tests?! Am I 
missing something? What is the correct way to run all tests before 
committing changes to main branch?

Besides, method registerOneExclusiveHandler of leoPluginsController was 
even more broken. It is most unlikely that any plugin used this method ever 
because it was replacing the handlers map with the array of one bunch 
containing one exclusive handler.
def registerOneExclusiveHandler(self, tag, fn):
   
   if tag in self.handlers:
   g.es("*** Two exclusive handlers for", "'%s'" % (tag))
   else:
   bunch = g.Bunch(fn=fn, moduleName=moduleName, tag='handler')
   self.handlers = [bunch]
The last line would broke all other plugins.


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: Possible bug in pluginsController.registerOneHandler

2017-04-06 Thread vitalije

Pull request is here <https://github.com/leo-editor/leo-editor/pull/468>
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: @clean nodes stopped updating

2017-04-08 Thread vitalije

I am not certain but it could be caused with the fixing of other bug I have 
reported recently in checkTimeStamp method. It used to report non-existing 
files in some cases as changed and to fix that the above method was changed 
to return True by default which means "file not changed". Try to test it 
with the version before this fix.
The change was introduced in b7638799d6 commit.
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.

Re: @clean nodes stopped updating

2017-04-12 Thread vitalije

I have bisected and found that the culprit is change in default setting.
Here is relevant commit:
2a0eca1635457b379e6e1cbfab6595e55afbd635 is the first bad commit
commit 2a0eca1635457b379e6e1cbfab6595e55afbd635
Author: Edward K. Ream 
Date:   Fri Dec 16 15:06:40 2016 -0500

Set @bool check_for_changed_external_files = False by default, and 
reference #262,
@bool check_for_changed_external_files may hang on network files.

Leo build: 20161216150641

:04 04 a946721dce8ae22363024fd5eedd9caea780e930 
81c2141e6c4404f6dab63b3d93971e9d7f930551 Mleo


 

On Tuesday, April 11, 2017 at 10:45:23 PM UTC+2, Edward K. Ream wrote:
>
> On Tuesday, April 11, 2017 at 3:40:38 PM UTC-5, Edward K. Ream wrote:
>
> > HTH.  We'll get to the bottom of this.
>
> And be sure to verify that your tool chain is actually updating the files 
> you think it is.
>
> The symptom that you must reload Leo to see changed files is quite 
> strange.  It argues that your tool chain *is* updating files, but we have 
> to check everything.
>
> We have to run Leo in a console so we can see all exceptions, especially 
> uncaught exceptions.
>
> For sure something strange is going on. A silently hidden exception, an 
> invisible popup, files not actually being saved, on_idle checks not 
> happening at all...
>
> 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: @clean nodes stopped updating

2017-04-12 Thread vitalije

Just add :
@bool check_for_changed_external_files = True


to myLeoSettings.leo in your configuration file.
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: @clean nodes stopped updating

2017-04-12 Thread vitalije


>
>
> Any comments?
>
> Edward
>

I think it would be useful to have some list of such changes in default 
settings with the commits they were introduced and short description of the 
reason why the change happened. When researching why some function of Leo 
got broken, it should be the first thing to check. That's at least what I 
have learned from dealing with this bug. 
Well, as I write this I am realizing that it would be possible to just use 
git blame on leoSettings.leo to see when some settings were 
introduced/changed. Maybe we can formulate a procedure for hunting bugs 
where this check could be one of the first steps. 

...

I have just tried to see the blame of leoSettings.leo in browser on 
github.com and it is too hard work for browser. I think that the @settings 
tree should be kept in some external file under git control. That way blame 
function of github.com would produce much smaller page. 

I wasn't very familiar with git bisect functionality and it took me some 
time to find my way through. At the end I think it is not overly 
complicated. Should anyone else try to do it, here are some tips. First I 
have cloned my Leo folder to /tmp/leo-trunk  (* could be any temporary 
folder). Then I made script (leo2) for launching Leo from that temporary 
location. After that I ran ```git checkout c235ff4```. That was the second 
last release (5.4.1). Then I ran leo2 and created a Leo file in 
/tmp/bug.leo with one @clean node in it. Then I made script that changes 
the content of the external @clean file. And I have tested that commit 
c235ff4 doesn't contain bug. Then I have issued following command: ```git 
bisect start``` and ```git bisect good```. After that ```git checkout 
``` and then again ```leo2 /tmp/bug.leo```, followed by 
executing the script to change @clean file. Leo didn't notice that file was 
changed. That is why I issued ```git bisect bad```. After that git has 
computed expected number of steps to find the problematic commit and 
automatically checked out some commit in the middle. The following steps 
were quite easy to perform:
1. leo2 /tmp/bug.leo#opens leo
2. run script to change @clean file
3. if Leo noticed that file was changed 
3.1 git bisect good
if Leo didn't notice that file was changed
3.2 git bisect bad
4. close Leo

I kept repeating this four steps until git announced that the first commit 
containing bug was ... I had 3 terminals open: one to start leo2, another 
to start script for changing @clean file, and the third terminal was for 
git commands. 

English is not my primary language. Maybe someone can reformulate this in 
concise and simple receipt, so that anyone who maybe contemplating to help 
with git bisecting Leo's code-base in order to find source of some bug, has 
clear and simple explanation of the process. 

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.

Re: @clean nodes stopped updating

2017-04-13 Thread vitalije



>
> I would have done something similar.  But you don't have to use a temp 
> folder. You can do the git bisect "in place", in your normal leo-editor 
> folder. When you are done, git will leave your folder just as it was.
>
> Edward
>
Yes, I knew it would, but in my Leo folder there are myLeoSettings.leo, and 
some plug-ins that can affect the behavior  of the Leo. If I have had  @bool 
check_for_changed_external_files set to True in my Leo settings, I wouldn't 
be able to reproduce the bug at all. Besides, I wanted to have normal 
operational Leo at hand, ready to create and edit script files used in 
experiment. Perhaps, for some (or even many) bugs, it doesn't really 
matter, but with some more dangerous bug it would. 
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: @clean nodes stopped updating

2017-04-13 Thread vitalije


>
> I'm dithering about @bool check_for_changed_external_files.  On the one 
> hand, it seems unreasonable not to enable it by default.  It's the expected 
> behavior for most editors and IDE's.  Otoh, there are rare performance 
> problems with network drives.
>

Is it possible for Leo to discover if some file path is in fact path to 
network drive? If possible then perhaps we can have the default settings 
set to True and refuse to check network paths and maybe warn user that 
those paths are not going to be checked.
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: quicksearch.py should not bind Ctrl-Shift-F

I have spent few hours trying to restore this shortcut without success. 
Apparently it is not possible to set the shortcut for this specific command 
in myLeoSettings.leo file. After several attempts I found that if one 
replace the find-quick-selected command name in shortcut specification with 
any of the core commands (for example clone-node) Leo obeys and add this 
binding. But it refuses to add binding to find-quick-selected command. It 
looks as if Leo can't assign bindings to plugin commands.

Vitalije

On Saturday, June 24, 2017 at 7:39:57 PM UTC+2, Edward K. Ream wrote:
>
> At present, install_qt_quicksearch_tab binds Ctrl-Shift-F to 
> ind-quick-selected.
>
> Imo, plugins should never make such hard bindings--they prevent any other 
> binding to Ctrl-Shift-F. Instead, the users should do so, as usual, in 
> myLeoSettings.leo.
>
> 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: quicksearch.py should not bind Ctrl-Shift-F

Finally I had to create a new @command node in myLeoSettings.leo. Its 
headline is '@command find-quick-selected2 @key=Shift-Ctrl-F', and its body 
is just 'c.executeMinibufferCommand("find-quick-selected")'. 
All that hacking just to restore one simple shortcut :-(.

It did get me thinking though. I have been using Leo since the days when Tk 
was the basic of GUI (don't remember exactly but for sure more than a 
decade now). I consider myself as an experienced Leo user and I do enjoy 
and use a lot of power it gives to its users. However, if it take several 
hours for one experienced user to adjust one shortcut, how long would it 
take for a newbie? It is not just question of a possible bug in Leo that 
caused so much trouble. Very soon I imagine this bug will be fixed and 
everything will be fine. It is question of design of Leo settings code. 

I would gladly admit that the way Leo deals with the settings is perfectly 
flexible and it is hard to imagine any kind of setting that can not be 
easily represented in Leo. But is this flexibility really worth its price? 
How much of that flexibility an ordinary user needs? I haven't touched 
myLeosettings.leo for years except for those few situations when something 
was changed in default settings that I was relying on. AFAIR every time it 
took me considerable time to reread the documentation and to relearn the 
proper way of making those changes. Today I thought that maybe my spelling 
of shortcut specification is not correct. Is it shift-ctrl-f or 
Shift-Ctrl-f or Shift-Ctrl-F or shift-control, or maybe it requires + 
instead of -? And everytime I try another combination I must close and 
reopen Leo to check whether Leo accepted my change or not. It is just too 
much required from user. User should not be forced to remember such trivia. 
 Perhaps, it is designed to accept any of the combinations mentioned 
before, but in case when it doesn't accept I can't be sure why. I thought 
maybe it is important where is @shortcuts node located. Does it have to 
have some label after @shortcuts? Does it need to be child of @keys node? 
Or maybe it is affected by something else? How much easier it would be for 
user to be offered one text-box to press any key combination and it 
automatically binds to selected command? 
That is another kind of flexibility. It doesn't offer too much flexibility 
for the programmer but it certainly offers a lot flexibility to users. 

I have to stop writing now. I am thankful for Leo as it is. I am not 
complaining because it caused me some trouble. I am complaining in the name 
of all those users who tried to use Leo and gave up because it wasn't too 
friendly to them. I have some ideas, but right now I must go.

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: quicksearch.py should not bind Ctrl-Shift-F


>
>
> Finally, I'm sure you can define bindings for plugin commands in 
> myLeoSettings.leo, e.g. I have: 
>
> find-quick-timeline = Ctrl-Shift-T 
>
> Well, I have created fresh clone of Leo code in /tmp/trunk-git. I have 
created myLeoSettings.leo in /tmp/trunk-git/leo/config/ (myLeoSettings.leo 
is atthached). And when I start Leo with 'python 
/tmp/trunk-git/launchLeo.py' and then execute print-bindings command here 
is what I get:
  ...
  Ctrl+Shift+P reformat-paragraph
  Ctrl+Shift+Q write-dirty-at-file-nodes
  Ctrl+Shift+Right forward-word-extend-selection
  Ctrl+Shift+U unformat-paragraph
  Ctrl+Shift+V paste-node
  Ctrl+Shift+W write-at-file-nodes
  ...

Clearly it doesn't bind find-quick-timeline command.

OTOH, if I change name of the command to edit-headline for example, then I 
get these bindings:

  Ctrl+Shift+Q write-dirty-at-file-nodes
  Ctrl+Shift+Right forward-word-extend-selection
M Ctrl+Shift+T edit-headline
  Ctrl+Shift+U unformat-paragraph

As you can see it accepts some commands but not commands registered in 
quicksearch.py plugin. Maybe it would be same regardless of plugin, maybe 
it is something wrong with quicksearch.py and how it registers its 
commands. But Leo as it is right now doesn't accept those shortcuts. 
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.


myLeoSettings.leo
Description: Binary data

How good Leo handles settings?

As I have mention in other thread I have some ideas about how can be 
improved Leo code that deals with the configuration and user settings.

Using small python script I have collected all settings from 
leoSettings.leo and created a dictionary whose keys are types of settings 
(int, ratio, float, string, color, bool and data) and values are lists of 
setting names.

Then I made list of all possible pairs (type, setting-name) and for each 
pair I put the current value in sqlite3 database table.

For each pair I have checked that the value returned by corresponding 
c.config.get(name) method is the same one that is returned by sql 
query for given settings name.

Then I have tested using timeit module, both methods of reading settings 
and the result is that using sqlite to retrieve settings value is actually 
faster then using plain c.config module. Speed gain is small, just about 
12.4%, but at least experiment proved that using sqlite for dealing with 
configuration is possible. 

What would be the benefits if Leo configuration code use database to store 
and retrieve settings. I believe that Leo startup code could be greatly 
simplified if the settings are available just by opening a database 
connection. There is no need to postpone any initialization because 
settings haven't been fully read yet. I have tried several times to 
understand what exactly is going on during initialization but I gave up 
every time because it was nightmare of indirect calls, halfway 
initialization, ... Almost all important members are initialized twice or 
more times. Once with the simple or dummy value, and later reinitialized 
with the correct one. Because of that there are everywhere checks if some 
dict is properly initialized or not. Arguably all that stuff could be 
written much simpler if c.config was present at the very beginning of the 
execution process. 

Attached to this message is sqlite3-config-benchmark.leo. Executing the 
script in its first node, performs all the steps I wrote about and prints 
in Log pane times for retrieving value of every setting 1000 times. On my 
computer it take about 6.5 s for c.config and 5.5 s for sqlite3 to give all 
those values. 

I am not so good in programming PyQt gui, but if all settings are kept in 
sqlite database, I could easily make single page web application and 
minimal REST server for accessing/adjusting all settings in web browser. 
Leo would need just one simple command to open local url in users default 
browser and user would be able to tweak any and all of the settings in 
browser. Server could be implemented in python and may actually run in the 
same Leo process or in other separate process. Leo would be aware of any 
such change in settings immediately. It would not be necessary to restart 
Leo to see changes. Maybe some of the changes would require restart, but 
most of them IMHO would not.
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.


sqlite3-config-benchmark.leo
Description: Binary data

Recovered nodes and empty lines difference

The other day I think I have read somewhere in Leo's code that it is 
supposed not to report in recovered nodes those nodes that differ in just 
one empty line. In my tool collection something is regularly causing Leo to 
report a lot of recovered nodes that differ not in one empty line but in 
two successive empty lines at the end of node. I am not sure what is 
causing those changes but I would prefer if Leo wouldn't report nodes that 
differ in any number of empty lines.
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: How good Leo handles settings?

ocumentation to figure where you went wrong and why 
your new setting is not accepted. If you are very unlucky, there can be a 
bug somewhere that prevents your settings to take place and there would be 
a lot of combinations to try (as there was for shortcut combinations). 
After you have tried all the combinations you finally start to suspect that 
maybe a bug is somewhere present.

But if you really like two have hierarchical view, you can have it very 
easily even if the data is kept in database. It would be straightforward to 
implement script for populating Leo tree with the values from database. 

I am not fooling myself that the init code can be simple. I can understand 
that it is inherently complex. But I would argue that by insisting on 
reading settings from Leo document makes it even more complex. Put it this 
way. After how many executed lines of code Leo has all needed information 
(means all relevant settings) to start reading user document? If it is N 
lines of code. I would argue that in that complex code it could be 
eliminated no less than 20% of N just by using database for keeping 
settings data. 

Finally I want to say that I am pretty determined to make an experiment of 
switching from present Leo document format to sqlite database. I have made 
few years ago a script to pack/unpack the whole Leo tree in fossil 
repository which in fact is a sqlite database. I am certain it is possible. 
I don't know how caching is implemented in Leo ATM. I remember that there 
was some discussion about the problems with the filenames and paths 
regarding caching mechanism. Well if Leo document was actually database it 
wouldn't need any other type of caching, because content of all nodes would 
be available from database. It just needs to check every node for possible 
external changes. I believe Leo is already doing this sometime during the 
opening document. 

I will be posting the progress of my work. When/if I make a working 
prototype I will make a list of changes I have made and then perhaps we can 
discus about the best way to package it.

@Edward, I would like very much that you don't take any of my criticism 
personally. I have very high respect for your engineering skills and I was 
enjoying every bit of your ENB-s and have learnt a lot from you. Maybe you 
won't like that much my idea, but even if you dislike it I would be very 
thankful if you help me by answering some questions about how Leo works 
ATM. 

Here is the first question. I wander what is the meaning of tnodeList 
attribute of SaxNodeClass in leoFileCommands module? In my experiments I 
intercepted the call to readSaxFile and instead of parsing an xml file, I 
wanted to provide the tree of SaxNodeClass items retrieved from database. 
My experiments were successful so far, but I have found that those 
tnodeList attributes were always empty. I don't know if they are supposed 
to be empty at that time or maybe in some special Leo files they can 
contain some information? I have tried to export LeoPyRef.leo to sqlite 
database and then to read it and combine them in tree of SaxNodeClass. 
LeoPyRef.leo can be opened that way but maybe that file doesn't use all of 
the supported features. 

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: How good Leo handles settings?

Someone asked how this proposition can help users. I wasn't clear about 
that. It won't help that much unless reloading is also addressed. But there 
are some settings that aren't so obvious when represented as a text. 
Colors, shortcuts for example. Now it is required that a user writes them 
as a text and there is possibility of spelling mistakes. Add to it need to 
open another Leo file, edit settings, save it, close it and then reopen 
your document again to accept new changes. Then you realize that the color 
is not so pleasing and you have to go again through the whole process. Very 
soon I gave up adjusting colors. I think that settings like colors, fonts, 
shortcuts and similar should not be edited as a text but as something that 
user can see and feel without understanding any particular syntax. They 
certainly can be kept as a text, but user should be allowed to edit them in 
more natural way.
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: Recovered nodes and empty lines difference

Thanks.

On Wednesday, June 28, 2017 at 4:51:56 PM UTC+2, Edward K. Ream wrote:
>
> On Wednesday, June 28, 2017 at 8:42:46 AM UTC-5, vitalije wrote:
>>
>> I would prefer if Leo wouldn't report nodes that differ in any number of 
>> empty lines.
>>
>
> Rev d1608d of master should fix this.  Let me know if it doesn't.
>
> 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: How good Leo handles settings?


>
> I would be happy with that, provided that a) settings can be organized 
>> and b) per-document (.leo file) settings are possible.  The best way of 
>> organizing anything is in a .leo file.
>
> As I wrote in the earlier post today, it is trivial in sqlite to open 
connection to several different databases (files). So it is easy to have 
one database file for settings machine wide, another one for settings per 
user, and yet another one for settings per folder (if I am not mistaken 
there used to be possible for user to define settings per project/folder, 
although I have never used that possibility). It is easy to make script to 
dump all relevant (leo, myLeo)settings-files in separate databases. 

@Edward, I have another question. Where is the point where the actual 
reading of Leo document ends and data is transferred in the tree. To be 
more concrete I have found in method getLeoFileHelper of FileCommands class 
the following lines:

c.setRootVnode(v)

fc.rootVnode = v

I thought that is what I was looking for, but on my surprise c.setRootVnode 
is empty method. It does nothing. 
So, how c commander gets the result of loading Leo document? If I knew that 
my prototype will be finished very soon. I have already made possible for 
launchLeo.py to accept '.db' as extension for Leo documents in sqlite 
format and it passes sqlite connection as theFile argument to 
getLeoFileHelper. It could be easily intercepted even before in 
LoadManager.openFileByName 
method and control transferred to the caller with complete new outline read 
from database. I just don't know where to transfer the tree restored from 
database and built in memory. 
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: How good Leo handles settings?

2017-06-29 Thread vitalije

On Thursday, June 29, 2017 at 4:16:38 PM UTC+2, Terry Brown wrote:
>
> Hey Vitalije, what are you working on exactly?  Not wanting to 
> duplicate any effort and wondering if you're working on the sqlite 
> settings idea or something else, and if you have any thoughts on the 
> sqlite approach separating file specific settings from the file they 
> apply to, vs. the current system's inclusion of those settings in the 
> same file? 
>
> Cheers -Terr 
>

I am sorry for the delayed answer. I worked last night and came to the 
state where I have a script that can turn any open Leo document into sqlite 
database with the same name except the extension (for example: LeoPyRef.leo 
turns into LeoPyRef.db ). I have changed the isLeoFile so that it now 
accepts extensions .leo, .db and zip files. I have changed openLeoOrZipFile 
so that it checks if it is a .db file that needs to be opened and if so it 
opens a sqlite connection and returns it instead of open file. Returned 
value from this method goes unchanged through some helper methods and 
finally arrives in readSaxFile. There I have simulated the parsing of xml 
nodes to tree of SaxNodeClass objects and switched the call to 
fc.parse_leo_file which returns SaxNodeClass root node with the call to 
retrieve the tree of SaxNodeClass nodes from database. It allowed normal 
start of Leo and opening LeoPyRef.db as it were ordinary LeoPyRef.leo. 
Later I have discovered that it would be better to intercept the normal 
reading procedure not in readSaxFile but higher up in call chain in method 
getLeoFileHelper. Because with the first variant the values stored in 
database were lower level so that they represent tree of SaxNodeClass nodes 
which would then be transformed into v-nodes. Instead it is easier to put 
v-nodes directly in database and then to retrieve higher level v-nodes tree 
and set it to c.hiddenRootNode in getLeoFileHelper.

That was the end of my yesterday work. Today I couldn't touch it until now 
and now I am going to finish the prototype that is able to open any Leo 
file stored in sqlitedb and to read settings from the good old 
leoSettings.leo and myLeoSettings.leo files. 

Next I plan to make a script that would analyze all settings files and to 
put all settings into database table like in the previous experiment I did. 
The only thing missing in that experiment I believe was additional field in 
database table which should contain level of settings source. For example 
default value should be on level zero, leoSettings (if it is something 
different than default I am not sure) on level one, myLeoSettings on level 
2 and finally settings in leo document would have level 3. Then querying 
database about any settings value can be performed like this:

select value from settings where key=? order by level desc limit 1;
Which could be explained like give me the value of given key with the 
highest level.

The idea is that every Leo document would contain all settings defaults, 
leoSettings and myLeoSettings and also any additional settings for 
particular document. When user changes myLeoSettings settings, earlier 
created documents will have outdated values. In that case executing simple 
command would update all values inside db leo document.

To summarize:

   1. user can keep all present settings unchanged
   2. user still can change settings in myLeoSettings.leo
   3. every new created file would have those settings embedded
   4. user can choose to execute simple command to update settings in any 
   Leo db document or perhaps Leo could automatically check the modification 
   time of myLeoSettings.leo and offer a user to update settings if they are 
   outdated

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.

A new file format for Leo documents (sqlite3 database file)

2017-06-29 Thread vitalije

well I would publish git branch with my code so that you can review it. I 
suppose my code style is not in accordance with the standard that is used 
in Leo, so I expect that I will have to prettify my code but I didn't 
bother to do it yet.  

I have mention on the other thread that I gathered some web browser client 
scripting skills (also fair amount of the server stuff skills). If Leo 
document were sqlite database I would be able to try something with the old 
idea of showing whole history of Leo tree but this time in web browser. I 
imagine that perhaps in web browser it would be easier to overcome problems 
with showing more historical versions of the same node. 

Also someone on this forum announced development of browser viewer of Leo 
documents. I expect that it could benefit also from sqlite file format and 
maybe some server stuff. 

I am sorry for very long post and for all mistakes I have made writing it. 
Hopefully, this time I have better explained the reasons and ideas that I 
had in mind. If I left something unclear please help me by asking questions 
and I would try to answer as concise as possible. 

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: A new file format for Leo documents (sqlite3 database file)

2017-06-29 Thread vitalije

setting leoID from os.getenv('USER'): 'vitalije'
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/config/leoSettings.leo
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/config/myLeoSettings.leo
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/core/LeoPyRef.db

** isPython3: False
Leo 5.5, build 20170624181042, Sat Jun 24 18:10:42 CDT 2017
Git repo info: branch = sqlite-format, commit = 1e6da9e97999
Python 2.7.6, PyQt version 4.8.6
linux2
wrote recent file: /home/vitalije/.leo/.leoRecentFiles.txt
vitalije@phenom:~/programi/leo/trunk-git$ python launchLeo.py 
leo/test/unitTest.leo 
setting leoID from os.getenv('USER'): 'vitalije'
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/config/leoSettings.leo
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/config/myLeoSettings.leo
reading settings in 
/home/vitalije/programi/leo/trunk-git/leo/test/unitTest.leo

** isPython3: False
Leo 5.5, build 20170624181042, Sat Jun 24 18:10:42 CDT 2017
Git repo info: branch = sqlite-format, commit = 1e6da9e97999
Python 2.7.6, PyQt version 4.8.6
linux2
.saved: save-new-test.py
....setting leoID from os.getenv('USER'): 'vitalije'
test of at.printError: La Peña
..s...
End of leoAtFile tests
..s
End of leoColor tests
.
End of leoCommands tests

End of leoConfig tests
..s..
.ss.s..s.ssssss...
End of typing tests
.
End of leoEditCommands tests.

End of leoFileCommands tests.
.
End of leoFind tests.
.
End of leoFrame tests.

End of leoGlobals tests.
.sss
End of leoGui tests.
...
End of leoImport tests.
...
End of leoKeys tests.

End of leoNodes tests.
ss..s..ss.EE...
End of leoUndo tests.
.
End of plugins unit tests
.@test print redraw count: 654
..all unit tests done
..
==
ERROR: runTest (leo.core.leoTest.GeneralTestCase)
@test rst3Test @no-head

--
Traceback (most recent call last):
  File "/home/vitalije/programi/leo/trunk-git/leo/core/leoTest.py", line 
211, in runTest
builtins.execfile(scriptFile, d)
  File "/home/vitalije/.leo/scriptFile.py", line 6, in 
rst3Test(c,p)
  File "", line 14, in __init__
  File "", line 54, in run
  File "", line 43, in clean
AttributeError: 'NoneType' object has no attribute 'replace'

==
ERROR: runTest (leo.core.leoTest.GeneralTestCase)
@test rst3Test default

--
Traceback (most recent call last):
  File "/home/vitalije/programi/leo/trunk-git/leo/core/leoTest.py", line 
211, in runTest
builtins.execfile(scriptFile, d)
  File "/home/vitalije/.leo/scriptFile.py", line 6, in 
rst3Test(c,p)
  File "", line 14, in __init__
  File "", line 54, in run
  File "", line 43, in clean
AttributeError: 'NoneType' object has no attribute 'replace'

==
ERROR: runTest (leo.core.leoTest.GeneralTestCase)
@test rst3Test doc_only_mode (set in headline)

------
Traceback (most recent call last):
  File "/home/vitalije/programi/leo/trunk-git/leo/core/leoTest.py", line 
211, in runTest
builtins.execfile(scriptFile, d)
  File "/home/vitalije/.leo/scriptFile.py", line 7, in 
rst3Test(c,p)
  File "", line 14, in __init__
  File "", line 54, in run
  File "", line 43, in clean
AttributeError: 'NoneType' object has no attribute 'replace'

======
ERROR: runTest (leo.core.leoTest.GeneralTestCase)
@test rst3Test doc_only_mode (set in options doc part)

--
Traceback (most recent call last):
  File "/home/vitalije/progr

Re: A new file format for Leo documents (sqlite3 database file)

I don't know how to publish my branch. When I try to publish it in 
leo-editor/leo-editor.git I get:
remote: Permission to leo-editor/leo-editor.git denied to vitalije

Several months ago I have forked leo-editor and made a pull request from 
there. When I look at that forked repository github reports that it is 8 
commits ahead and 735 behind master. I have no idea how to synchronize 
them. And I don't know what would be the effect of those 8 commits on 
creating pull request.

I tried to fork it again, but github gives me the same fork I have already 
made. When I tried to delete that fork, I was seriously warned so I didn't 
dare to delete it.
What should I do? My local branch is updated to the latest commit of 
leo-editor/leo-editor.git.

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: A new file format for Leo documents (sqlite3 database file)


Ok. I found my way around. I have pulled from my fork into working folder, 
merged it and then pushed branch to my fork of leo-editor. After that my 
sqlite-format branch was in sync with the master and I was able to create a 
pull request that consists only of my recent work. I had to manually copy 
one file that contained some changes that I have made several months ago 
and were out of sync with the current master.

I forgot to push script that exports Leo tree in database. Without it new 
code can't be tested. That reminded me that I haven't done anything about 
saving to db files.
I am going to do it ASAP and then to push it again.
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: First results with sqlite-format branch

It should be used like this:
1. open ordinary .leo document
2. issue command save As and type in filename that ends with '.db'.
3. ATM it will save only outline in db but that outline contains all nodes 
even those that are located in external files.
4. newly created .db file can be opened after that with `leo 
/...path-to-db-file/.db` 
5. after opening db file Leo window will have minimal size because in 
current implementation I neglected window position and size information 
that should be returned after reading Leo document.

This is the "new" except syntax.  It must always be used in Leo.

I'll keep that in mind. 

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: First results with sqlite-format branch

I was executing save-as to '.db' command many times and for the safety 
reasons I have always chosen /tmp/test.db /tmp/test1.db ... filenames. 
Before executing my code Leo was writing external files and complaining 
about overwriting existing files and/or non-existing folders. That was a 
bit annoyance and I have disabled writing external files when saving to 
sqlite db. If you make change in the node that belongs to external file, 
that node will be preserved in database, but after loading from database it 
gets overwritten by content of the node from external file which was not 
changed. Try making changes in nodes outside external files or enable 
writing external files in   fc.write_Leo_file:


if (not g.SQLITE) and not outlineOnlyFlag or toOPML:

g.app.recentFilesManager.writeRecentFilesFile(c)

fc.writeAllAtFileNodesHelper() # Ignore any errors.



Next I am going to make database restore window position and size after 
loading.
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: First results with sqlite-format branch

I have just pushed new version that respects window geometry:

   - stores it when saving to db
   - restores window size and position when opening db file

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: First results with sqlite-format branch

I have also noticed in Leo's init/loading code that it restores also 
archived position. I wander is there somewhere a list of those ivars that 
should be restored after opening Leo document? Or should I hunt them one by 
one?

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: First results with sqlite-format branch



On Friday, June 30, 2017 at 10:03:33 PM UTC+2, Edward K. Ream wrote:
>
>
>
> On Friday, June 30, 2017 at 12:17:30 PM UTC-5, vitalije wrote:
>>
>> It should be used like this:
>> 1. open ordinary .leo document
>> 2. issue command save As and type in filename that ends with '.db'.
>>
>
> Hmm.  I issued a Save To command and afterward closed without saving.
>
> When I reopened leoPy.leo I got:
>
> Internal Leo error in checkForChangedNodes
> no vnode ['fc.getWindowGeometryFromDb', "def getWindowGeometryFromDb(self, 
> conn):try:\nd = dict(conn.execute('''select * from extra_infos 
> \nwhere name in ('width', 'height', 'top', 
> 'left');''').fetchall())\nexcept sqlite3.OperationalError:\nd = 
> {'width': 600, 'height': 400, 'top': 50, 'left': 50}\nreturn d\n", 
> 'vitalije.20170630200802.1', []]
>
> Called from , run, load, doPostPluginsInit, loadLocalFile, 
> openFileByName, readOpenedLeoFile, openLeoFile, getLeoFile, 
> readExternalFiles, readAll, read, readFile, createOutlineFromCacheList, 
> createOutlineFromCacheList, createOutlineFromCacheList, 
> createOutlineFromCacheList, checkForChangedNodes
>
> Please report this error to Leo's developers
> creating recovered node: fc.exportToSqlite
>
> We are going to have to be very careful about switching between .leo and 
> .db files.
>
> Edward
>
I can't reproduce this error on my machine. 

I guess it has something to do with cacher and not changing the filename in 
saveTo command. As I understand reported warning cache expects that there 
are present in fc.gnxDict vnode that I have recently added. It maybe 
because cache data is dated before I add that method. Try to repeat the 
process but, after at least once saving .leo version of file to update 
cache data.
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: First results with sqlite-format branch

2017-07-01 Thread vitalije

I have just published new version of sqlite-format branch.

   1. added support for preserving ratio and secondary_ratio in db and 
   resizing panes after opening database
   2. commander instance has sqlite_connection ivar. When opening database 
   this ivar is set to connection instance
   3. at.readFile now checks if external file has same digest as it used to 
   have at the moment of exporting tree to database.
   Md5 hashes for every external file is now kept in database. In prior 
   version at.readFile would delete tree created from database and recreate it 
   from cache. It was unnecessary duplication of work.

At least one thing is still missing. When saveAs or saveTo fileName is 
changed at that time connection should be closed/opened. It is next to-do 
item.
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.

sqlite-format ready for testing

2017-07-01 Thread vitalije

A branch sqlite-format is ready for testing. At least for brave testers. 

As Edward pointed out it is still highly experimental. But I am developing 
sqlite-format branch using it.

Please report any problem on this thread. I will try to fix it ASAP.

Until someone reports a bug, I think I'll be trying to do something about 
settings in this branch, but about that in another thread.
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: sqlite-format ready for testing

I just  bumped into this old thread regarding use sqlite as file format for 
leo 
<http://groups.google.com/group/leo-editor/browse_thread/thread/dff0c165e2211691>
 
Apparently it is dated roughly 9 years ago. 
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: Experiment: use README.MD to document branches

Ok, it is on my to-do list for sqlite-format branch.
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.

sqlite-format and settings - ideas

 

As my experiments proved it is possible to collect and transfer all 
settings from traditional .leo settings files into sqlite database. If we 
use sqlite as file format for outline data it is trivial to keep the 
collected settings in the same file. 

A problem can arise when user changes any of relevant settings files: some 
.leo.db files can have outdated settings embedded.

One possible solution would be to have sqlite database files in every 
folder where traditional .leo settings files are located and to 
automatically keep them in sync whenever saving .leo settings file. Let us 
imagine we already have done this. In that case, during the init phase, Leo 
can instead of reading and parsing all traditional .leo settings files, 
read settings directly from the db settings files. It is certainly possible 
to make it this way. 

However, let us discuss what would be the consequences of outdated 
settings? First of all, we can have new command `update-embedded-settings` 
which can parse relevant files and collect current version of settings in 
.leo files and update .db file settings table. Leo can warn user that the 
settings in db document are outdated and to offer updating them or keeping 
old values. It can be done automatically behind the scene and then 
executing reload-settings command. It will happen once per every leo 
document after each change in settings files. When creating a new Leo 
document it would get all current settings embedded in database file. 

But let us discus how and when settings files change? There are two cases I 
believe:

   1. 
   
   git pull and leoSettings.leo has been changed
   2. 
   
   user edits myLeoSettings.leo or any other settings file.
   
Now, whenever leoSettings.leo is changed we can also update leoSettings.db 
and both files would be pulled at the same time. Global leoSettings.leo 
file has unique location per installation and it is trivial to find path to 
it and to its .db version. So syncing automatically those settings is 
trivial.

In the second case we can perhaps assume that myLeoSettings.leo file won’t 
be edited by some other editor than Leo itself. Perhaps we can also assume 
that user would use menu command to open settings file. This may be a bold 
assumption because user can manually navigate and open that file. But let 
us just pretend that it is a fair assumption to make. In that case user 
would have to open myLeoSettings.leo through the menu command. What if we 
recreate outline of that file based on values and unls directly from 
database not from actual file on disk. User is then able to edit settings 
the way he/she likes and when the editing is done outline is stored once 
again in database and maybe in .leo file on disk. When I say in database I 
didn’t specify which database file. Well it could be one fixed database 
file located in leoHome directory. It can have all settings kept in a table 
along with their unl origins. In that case all settings documents can be 
recreated from the one database file just by selecting a group of settings 
with unl that starts with some path. If implemented that way, Leo would on 
start check two databases at well known locations (one in installation 
folder and one in ~/.leo). It would collect all the settings from the first 
(installation folder database), and only those settings from the second 
database that have unls that starts with one of the paths that Leo would 
look up for settings: (settings per user, or per folder). From all those 
collected settings Leo can update the settings table in db Leo document 
itself. That way g.app.config and c.config can be available in just a few 
lines of code at the very beginning of init phase.

The only restriction for user is that they must not open any .leo 
file directly from disk but through the menu command. IMHO it would be very 
small restriction for users to suffer and it would bring in the future 
opportunity to considerably simplify init code.

For the period of adoption we could keep current settings mechanism but on 
every save we can behind the scene build and update those two database 
files. After period of adoption, we can deprecate and remove old 
.leo files so that users can never see them again unless through 
menu command. Then we can start simplifying the init code. 

Your opinions please.

Vitalije

PS: I would be glad to implement any of the two possible solutions, but my 
choice would be to restrict users to open settings file only through menu 
commands and in the future get rid of those files and keep them only in two 
databases. 

-- 
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, v

Re: sqlite-format and settings - ideas

And once more, I am imagining web browser UI for editing settings once they 
are in stable well known locations. But one step at the time. 

-- 
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: Experiment: use README.MD to document branches

Done at  96456e8 for sqlite-format branch.

-- 
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: sqlite-format and settings - ideas


>
> I don't see a clear reason for all settings to be in each Leo outline, 
> I think users are used to personal and default settings that are 
> separate from file specific settings. 
>
> Cheers -Terry 
>

That is what I thought as first solution. The reason I had in mind for the 
second variant was that we can possibly reduce search trouble for all 
folders and files to check. If everything is inside database file the only 
sacrifice we have to make is to allow some documents to have outdated 
settings. In return we get the ability to have c.config working in fewer 
steps. Perhaps it is not so important as I thought it would be. OTOH, maybe 
it could have some advantages. For example it maybe useful sometimes when 
sharing Leo documents to share them along with all their settings. If 
shared file relies on some settings from myLeoSettings.leo, then it could 
happen that when opened on some other machine it won't look/work the same. 

In case we have parallel sqlite and xml versions of settings, we have to 
sync them and to check if user edited one and not the other. Also we have 
to keep all present code in case there are no sqlite versions of files. We 
won't be able to remove anything in init code and no simplification that I 
hoped for. The second solution was in essence plan for migration to new 
file format and then simplifying by eliminating unnecessary blocks of code. 

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.

quicksearch history of searches

Commit f1f4d43 adds support for search patterns history in quick search.

To see it just enter 'h' as search pattern and the list of last 30 search 
patterns will be displayed. By clicking in any of them that search is 
repeated.

Vitalije

PS: I wished to enable accessing values of previous search patterns by 
pressing Alt+Up or Alt+Down or some other key combination. I have tried to 
change eventFilter in quicksearch plugin but apparently that eventFilter is 
not used. Suppose we have implemented two commands 
`quick-search-previous-pattern` and `quick-search-following-pattern`. How 
can those commands be bind to Alt+Up and Alt+Down when focus is in 
quicksearch?

-- 
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: Oops: 58d7b463504 merges sqlite-format branch into master

I thought that I was merging master into sqlite-format not the other way. I 
am not sure how to undo it. To checkout previous commit and then to do what?

On Monday, July 3, 2017 at 5:12:39 PM UTC+2, Edward K. Ream wrote:
>
> I don't think I did this, although I can't be sure.
>
> Vitalije, could you please undo this? The sqlite-format should remain 
> separate for awhile longer.
>
> Thanks.
>
> 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: Oops: 58d7b463504 merges sqlite-format branch into master

I am looking through git documentation to figure out  how to undo. One 
advice I have found was to run command:
```git log --graph --oneline```

When I did this is what I get:



Now it is suggested that I should execute command:
```git revert --mainline 1 ```
But I don't know which commit.

-- 
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: Oops: 58d7b463504 merges sqlite-format branch into master

I have tried two reverts and it did something. In diffs of last revert I 
can see my changes being marked red  as deleted. 
I don't know if it reverted complete.
I am sorry to tell but, I want be available for the next two days. I hope I 
didn't broke something.
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: Oops: 58d7b463504 merges sqlite-format branch into master

I am back and glad to see that this issue has been resolved. However, when 
I tried to continue work on my sqlite-format branch I couldn't make it in 
sync with current master without loosing all my work on sqlite-format. 
After several unsuccessful attempts I decided to give up and to start new 
branch starting from current master and manually overwriting with my 
working files. The new branch is called sqlite-leo. 
IMO it is safest thing to do. After all, loosing a bit of history from 
sqlite-format branch is not big deal.
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: sqlite-format and settings - ideas


>
> in the same file as the XML format does.  Switching Leo to a Sqlite 
> file format certainly solves that problem, although it's a way bigger 
> solution scope wise than I would have contemplated.  Being familiar 
> with DBs and SQL I'm not opposed to it myself, but are we really 
> discussing dropping Leo's XML format here?  People more familiar with 
> XML than SQL might find that disagreeable. 
>
> Yes, we are discussing dropping Leo's XML format. It is continuation of 
the discussion since 9 years ago. 
IMO XML has no real advantage over sqlite. Sqlite format easily crosses 
platform/language boundaries, it is stable, widely spread, (advertised as 
small, fast and reliable choose any three). It is designed to be safe. What 
would happen if power is out while writing XML file to drive - file gets 
corrupted. Sqlite has protection against this situation if power is lost 
while committing to db file. The only thing that is lost is just last 
transaction. Db file remains readable and its content is exactly the same 
as before last transaction started. Currently Leo has many (countless) 
files on disc for its normal operation. With sqlite almost all those files 
can be stored in one or two db files. If we are to believe benchmarks on 
sqlite, it is faster than filesystem when files are under 100k. (See 
<https://www.sqlite.org/intern-v-extern-blob.html>).

The only advantage of XML is that it is human readable, but I really doubt 
that it can add any benefit to user. I would argue that in fact sqlite file 
is more human readable than XML if one uses any of many available tools for 
reading/manipulating sqlite db files. It is much easier to understand and 
change something in sqlite representation of Leo document than it is in XML 
version. 

>
> If we do drop XML, I suggest making a stand alone XML -> DB converter 
> rather than maintaining XML support in Leo's core.  Leo can always 
> invoke the converter as needed (it would be part of the Leo 
> distribution), but it would be a good chance to trim code from the core. 
>
> Yes that is good idea. I have created small script/module 
leo.extrenal.sax2db which takes as argument path to .leo document and 
creates .db version of it in the same folder.

 

> Also we need to think a bit about the DB design - I think Vitalije you 
> mentioned using lists of gnxs in a single field in a record to 
> represent children... should consider that approach vs. something more 
> relational. 
>

I agree it is not normalized representation. But in current implementation 
Leo just stores every vnode in db file, and few additional information like 
position and dimensions of app window and md5 hashes for every external 
file related to Leo outline and currently selected position.
When opening db file Leo reads all that data at once and recreates its 
runtime data structures. It doesn't use connection at all in the rest of 
code. This is good enough for now, but it certainly can and should be 
improved if Leo starts to rely more on db in the rest of its code. 
 

> Also I think we'd be missing a big opportunity if we don't have a clean 
> break between the DB reading code and the DB connection, i.e. support 
> the possibility of using DBs other than sqlite.  If the code's using 
> the Python DB API (PEP 249) then we're probably already in good shape 
> here, just saying we should isolate any sqlite specific code.  Here I'm 
> talking about dropping the XML format, not just the settings stuff. 
>
>
AFAIK sqlite3 module in Python standard distribution is compliant to Python 
DB API. Maybe the only thing different is that in sqlite3 connection 
implements mehtods of cursor objects so it is not needed to create cursor 
to invoke some method. If we decide to switch to some other DB library it 
would be trivial to create wrapper for its variant of connection (to keep 
similar with sqlite3). Nothing special about sqlite is used. 


 

> Exciting times :-) 
>
> Yes, they are !

 

-- 
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: sqlite-format and settings - ideas

I tried to extend sax2db (leo.externals.sax2db) script to collect settings 
data from outline and then I have realized that it would not bring any 
benefit. I have made a function which would examine outline and collect all 
settings from it and store the result in db table. However, Leo currently 
supports several kinds of at-if nodes in settings tree. Presence of such 
nodes makes function that traverses tree and collects settings an impure 
one. Collecting settings by traversing tree can make list or dictionary of 
currently valid settings, but same outline can give different result if 
traversed again. That prevents us for making any benefit of cached 
settings. 

One way to deal with this would be to give every setting row in database 
one extra column which would contain list of all at-if conditions from its 
parents in outline. Then after opening db file Leo would have to evaluate 
all conditions and if they are True for all ancestor nodes those settings 
would make to final list of valid settings. Though it can be done, I would 
ask how many users do use such nodes? How many of them use at-if variant 
with arbitrary code in body that calculates if condition is True or not? 
At-ifhost and at-ifplatform perhaps, might be considered as immutable 
constants between two launches of Leo. They would rarely change and even if 
they do change (changing the name of computer, for example) perhaps user 
would want to change this headlines anyway.  In that case it would suffice 
to run sax2db once again on settings files after such change occur. 

Is it necessary to support such flexibility? Does anyone uses it and for 
what? Maybe it can be added to list of special cases like ifhost and 
ifplatform. If there were not support for at-if nodes with arbitrary code 
in body, sax2db could collect settings and cache them in a table. Leo could 
in a few lines of code have fully functional and properly filled 
g.app.config and c.config at the very beginning of execution. That could 
greatly simplify Leo init code. 

Once again it would make no difficulties for sax2db to support all at-if 
nodes exactly as Leo supports them now under one restriction: that code in 
body of at-if node gives always same result for one settings file. Under 
such restriction it would be reasonable to cache settings and use them from 
cache. Cache would be automatically updated when settings are edited by 
Leo. But if that restriction is left then there would be no easy way to 
guarantee validity of cached settings. 

Also it is worth noting that Leo already supports settings per machine so 
the functionality of at-ifhost can be achieved by using more setting 
documents. So even if we drop support for at-ifhost user can achieve same 
effect with extracting machine specific settings in separate document.

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: sqlite-format and settings - ideas

Well this was a nice surprise! When I looked in 
leo.core.leoConfig.ParserBaseClass and its methods I have found that at-if 
is not supported! Instead at-ifenv is supported. It gives a chance for 
collecting all settings in a table with two additional columns one for host 
condition and the other for env condition. During the init phase Leo can 
filter table accordingly checking host and env conditions. 

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: sqlite-format and settings - ideas

Still looking in leoConfig parser methods. In Leo documentation there is no 
reference about at-outlinedata and I am not sure how they are supposed to 
work, but one thing seems like a bug to me. Shouldn't method doOutlineData 
return 'skip'? If I am not mistaken at-outlinedata is supposed to have its 
value as xml represented its subtree. In that case parser should not 
descend into subtree. I might miss something or have wrong impression of 
what at-outlinedata is supposed to do. 

Also at-outlinedata should be documented somewhere. Maybe it is but I 
couldn't find documentation.

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: sqlite-format and settings - ideas


>
>
> I do not understand why you are concerned about settings. This seems 
> like a natural migration path:
>
> I am not so much concerned with the settings  as I am concerned with Leo's 
init code. I have a strong feeling that the way Leo handles settings at 
present complicates init code. Surely, it has some beauty in the idea that 
settings can be represented the same way as document outlines are and that 
the same code that reads document can be used to read settings as well. 
There is something self similar, something fractal-ish in that approach. 
However, it makes init code complicated more than it must be. There is also 
great flexibility in the way user can adjust settings. But all that 
flexibility and beauty vanishes in a moment when user wants to do simple 
thing, to set shortcut or change font or color of something. I believe that 
just a few of Leo users can and do appreciate that kind of beauty because 
most of them never bother themselves to read Leo's source. However, it may 
be that many more users are being annoyed by the complexity and amount of 
work that is required to change one simple keystroke or color or font. Who 
knows how many potential users have tried Leo and gave up too quickly 
considering themselves as not enough clever or skillful to use Leo. Yes, we 
know that no question and no problem reported to this forum stays 
unanswered longer than a day or two. But we can't be sure how many users 
never dared to post a question.
 

> - When in "sqlite mode", saving an outline will create x.leo.db.  This 
> includes settings files.  Similarly, reading an outline will read x.leo.db.
>
> - Retain Leo's startup logic, completely unchanged.  This will load 
> settings from leoSettings.leo.db and myLeoSettings.leo.db.
>
> Yes, this is already done with the code in sqlite-leo branch, and that 
branch can be used that way without any further implications on Leo's code. 
However, as I have stated in README of that branch, I am striving to make a 
prototype of Leo that can have much simpler init code, Leo which would 
allow user to change any setting and see its effect immediately, and in 
which user won't have to imagine what color or font would look like while 
entering text value for those settings. I believe that sqlite as document 
format has great potential and that it would be appreciated enough by users 
so that the old xml format can be deprecated. I certainly don't want Leo to 
loose anything or to be broken in anyway. I have no intentions to force any 
user to change his/her habits and preferences. I believe a smooth 
transition to sqlite format is achievable. Behind the scene Leo would make 
db versions of xml settings files. And maybe it can be announced that 
support for xml settings files will be dropped in Leo 6.0 or 8.0. Support 
for reading outlines in xml format need not to be dropped ever. Just 
reading settings from xml files. Meanwhile users can edit both versions of 
file formats and Leo will keep up with both versions. But on the day that 
Leo is allowed to ignore xml settings and can rely on settings from db only 
versions, much of the init code can be reduced. 

Heroic alternatives threaten to break Leo in subtle ways.
>
>
I certainly would not want to do that. But without such attempts we are 
doomed to find local maximum only and maybe we will miss opportunity to 
reach much higher maximum in close neighborhood.

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: sqlite-format and settings - ideas

Hi Xavier,
 

> ... it takes me to what could be a naive question from my part but, is it 
> really impossible to simplify the init code without requiring the switch to 
> sqlite-based settings? It seems strange to me that the access to those 
> settings cannot be made *independent of the underlying source* by the use 
> of an intermediate abstraction layer or proxy or whatever you call it... I  
> mean that it should be possible to have also a real-time settings edition 
> experience by editing Leo outlines, shouldn't it?
>

I don't know any other way. Perhaps there is another and maybe even better 
way, but I can't imagine it. At present Leo uses same code to read user 
document and to read settings files. One of the settings that is very 
important is enabled_plugins. It can be defined in leoSettings.leo, in 
myLeoSettings.leo, in LeoSettings.leo, inside working folder in 
leoSettings.leo or even in user document. Leo can't be fully initialized 
without initializing plugins and it can't figure out what plugins to load 
until it has processed all possible settings documents. Leo needs all of 
its power to analyze outlines with settings, but all that power should be 
initialized first, and to fully initialize it, it needs settings data, so 
there we are at the beginning of a loop. It is amazing to see how it is all 
done, but to understand and be confident that you understand well what is 
going on is very hard. That is why I believe if Leo had access to settings 
data using some other method not its tree traversing and parsing abilities 
then init code could be much simpler. 

I hope this makes sense.

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: sqlite-format and settings - ideas


>
>
> Thanks for the thorough explanation. But you don't need a GUI app to 
> read an XML, as you don't need a GUI app to read from an SQLite file. I 
> understand that you need to read all the settings files to be able to 
> fully initialize Leo, but you don't need (or should not need) al Leo's 
> machinery to read the settings files. Even if they are .leo files. 
> Clearly the part that needs to be changed is that "Leo needs all of its 
> power to analyze outlines with settings". It may be the case at present, 
> but it should not. 
>
> I agree on that, but at present Leo relies on the same machinery for 
analyzing settings and reading documents. That makes things more 
challenging for init code.
 

> It should be possible to take the code which reads Leo files apart from 
> the rest and see if there are parts in the settings that need a delayed 
> evaluation (o some other kind of lazy evaluation) to succeed and decide 
> on them on a case by case basis. It could even be handled with a 
> dependency tree if needed, but it cannot be a closed loop. 
>
> It isn't really a closed loop but one very convoluted. Machine can find 
way out and Leo successfully starts up, but it is very hard for human brain 
to follow that convoluted path and understand what is going on. I also 
agree that it should be possible to separate code that reads settings and 
code that reads outline. 

I'm sorry I don't have the time at this moment to take a look at the 
> initialization code to help further in this envdeavour, so you are in 
> your right to ignore my comments completely and go on with the best 
> solution you can achieve. But from an architectural point of view, the 
> need to simplify the initialization code should not imply the need to 
> change the form in which settings are stored. 
>

It is not question of storing settings but collecting them that complicates 
init code. Right now I am working on standalone script (sax2db) which 
should read settings file, analyze settings in it and produce a collection 
of valid settings in that file, (and finally to store collection in db, but 
let us ignore this for a moment). I try to use as little as possible from 
Leo machinery that requires any kind of initialization, and to use as much 
as possible of Leo's code that can stand on its own without special 
initialization requirements. If I succeed in this maybe that code could be 
used even without sqlite just to make g.app.config and c.config available 
sooner in init phase. 

As you can see even if I work towards adoption of a new format for Leo 
documents, some results of those endeavors may be found useful even without 
changing format. 

I don't see why those settings affecting those objects can be changed and 
> we can see their immediate effect in real-time when they are in Sqlite and 
> cannot be when they are in an outline. 
>
 
Maybe I didn't make myself clear. It is not my claim that it can't be done 
without sqlite. What I wanted to say is that using the same code for 
reading, analyzing, collecting settings from outlines and for reading and 
dealing with documents makes it impossible to simplify init code. OTOH 
complicated init code makes it difficult to show real-time changes and 
requires restart. Maybe use of sqlite for settings could have been just an 
excuse to introduce new separate code for settings. But in my mind idea of 
using sqlite as a file format have been for years, and not only in my mind 
but also in this forum it was mentioned 9 years ago.

On the road to sqlite file format next step is dealing with settings. That 
is why I have started this thread. To discus about best way to deal with 
them. It may look like I have lost my compass and mixed several goals into 
one, but the truth is I am aware that these are separate issues that just 
happen to lie on the road that leads to my final goal. I try to deal with 
them one at the time. This time it is Settingsville that I have to pass 
through. 

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.

cleaning of leoConfig.ParserBaseClass

2017-07-06 Thread vitalije

Several methods that were not used for some time in this class are removed. 
All unit tests pass but if someone notices anything suspicious regarding 
settings, please report. 
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: Leo's run levels

2017-07-06 Thread vitalije


>
>
> So I guess a first cut would be working out the order of creations and 
> deferments in the UI startup code. 
>
> Cheers -Terry 
>
If I may add to this idea, it would also be very useful to have a list of 
ivars that somehow represent current state of Leo application, ivars that 
get changed through user interaction. When reloading Leo application we 
don't want to change any of this ivars. For example in this list belongs 
currently selected position, scroll positions, ratios of panes, position 
and size of window, undo/redo history, history of visited nodes, search 
patterns history, ...

In clojurescript world there is a figwheel tool which reloads client code 
in browser as soon as is changed on disk. Clojurescript programmers are 
advised to use different macros for defining such ivars. For all things 
that need to change after reload one should use `def` command, and for all 
things that should preserve their value after reload one should use 
`defonce` instead of `def`. That way during development code stays 
reloadable most of the time.

There are no `defonce` in Python, but it can be simulated and it can be 
matter of convention.

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: sqlite-format and settings - ideas

2017-07-07 Thread vitalije


>
>
> I don't agree. The concurrency problems will, but the problems to have 
> Sqlite files under git are here right now 
> <https://stackoverflow.com/a/551409/5104752>:
>
> *In short, you’ll probably be unhappy trying to keep a database versioned 
>> using a source control system.*
>
>
> There is no need to add db file to git. External files are kept in git. If 
you want any part of Leo outline to be kept in git, you can make it 
external file and add to git. 
I would argue that can give you even better diffs. It would be trivial to 
make script that would produce outline structure as plain text file which 
can be added to git. If you make a very simple change like sort siblings 
 it can produce totally confusing diffs, when in fact the only thing that 
is really changed is order of nodes in outline. Yes that order would make 
also changes in external files but diffs of such text representation of 
tree structure would give very clear explanation why all those changes in 
external files did happen. 

Further more, you can dump content of db to sql and add it to git.

There is also possibility to have in db all history of all nodes.

...unless you use Fossil as VCS, of course!
>
> But then, *we all have to have clear in our minds *that using Sqlite as 
> the next Leo file format *is forcing us to take those files out of git, 
> or to use Fossil* as VCS. Yes or yes. And those are important facts!!
>

Although I personally would salute such change, I strongly disagree on 
this. It is not the case that using sqlite as file format or even using 
fossil for keeping history of every node in outline is forcing any change 
in VCS used for project as whole. 


> XML limitations, which are now starting to show now, like reloading 
>> settings time.  
>>
>
> I insist: reloading settings time in Leo is not a limitation of its XML 
> file format! As I have already tried to explain, that is a separate problem 
> which can be solved by its own and which should be independent of the 
> backend used as storage.
>

I agree with you on this question. It is not XML format that prevents fast 
reload. I believe it would be possible to make Leo reloadable even with XML 
as format. But I prefer to make it reloadable using sqlite. Among other 
reasons is that if you want just small fraction of XML file you have to 
parse it whole. OTOH, opening db file gives you opportunity to ask for any 
piece of information that you are interested in. You can even ask for some 
aggregate values of interest without loading whole file. Setup for reading 
XML file is much larger than for opening and querying db. If you want to 
make small change in XML document it requires even larger setup. It may be 
very well matter of preference and we should not discuss preferences, but 
my preference for file format is sqlite. After all if when finished 
sqlite-leo prototype not all users would want to use it and if there will 
be some who prefer XML, support for XML files need not to be abandoned ever.

>
> I agree in that exploration or prototyping is a good way to go forward, 
> but well... problem anticipation is also a great tool! It can help you save 
> a lot of time or even avoid some crashes. Shouldn't I warn you if I know 
> there's a big hole in the road some meters in front of you? ;-)
>
>  Thanks for the warning. 

But again: I would separate the VCS integration question from the Leo 
> storage format. They are different issues which deserve deep analysis and 
> design on they own.
>  
>
>> Yes please! I really would like to understand how did you did to have 
>> this nice diff 
>> <http://www.google.com/url?q=http%3A%2F%2Fmutabit.com%2Frepos.fossil%2Fpanama-papers%2Ffdiff%3Fsbs%3D1%26v1%3D255e79b046584a36%26v2%3Dcbfe8929edf64212&sa=D&sntz=1&usg=AFQjCNE4vUh4DdtIcaZ7QQkoSfOY0RaT1Q>
>>  
>> for your outlines in Grafoscopio! At which moment do you use the STON 
>> format? Is it just before making the diff?
>>
>
It is ordinary page generated by fossil (one file executable, that needs no 
configuration nor installation, just download one file) on files that are 
added to fossil repository. 
Fossil supports several different diff views, graph of repository, wiki 
pages, issue tracking fully configurable by user, tech notes, ... 

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.

sqlite-leo and collecting settings

Recently, I was working mostly on a leo.external.sax2db script (*part of 
sqlite-leo branch). Idea was to make stand-alone script that can parse xml 
leo document and produce sqlite db version of it. The first part of it was 
to transfer outline with all vnodes and their ivars including v.u. This 
part went smoothly and it is capable of turning any Leo document from XML 
file to its db version.

The second part was supposed to collect all the settings from the outline 
and store them in separate table. I wished to implement it in such way that 
it uses from Leo code base only those objects that are easy to instantiate, 
that don't require special init code. And I almost made it. It searches 
tree and collects all settings creating table of tuples:

(gnx, kind, name, value, conditions)

conditions is a list of conditions that affect this particular setting. A 
condition may have any of the following forms:

   - ifhost: hostnames,...
   - ifenv: env values,...
   - ifplatform: platform,...

In tuple this list of conditions is joined with some special separator 
'|#|' which is unlikely to be part of hostname, environment vars or 
platform names.

The idea was to store all those tuples in database table and on opening Leo 
document to calculate conditions and select only those settings whose 
condition list is True. Empty list of conditions is considered to be True.

I have been implementing one by one all needed functions for dealing with 
different kinds of settings and everything went smoothly until I came to 
at-commands, at-buttons and at-outlinedata kinds. Those kinds require 
g.getScript, and it requires operational commander. Now I had two choices:

   1. to re-implement g.getScript without commander and that means 
   re-implement write file logic with all possible at-directives, or 
   2. to raise white flag and admit that it was a bad idea in the first 
   place

This get me to think again about the reasons that lead me to this. I wanted 
an easy way to change shortcut, or color or font and see the effect without 
delay. I wasn't feeling very comfortable with the idea of using PyQt to 
implement those features and I wished to implement gui for those parts in a 
web page where I feel more like being at home. For creating such web page I 
needed access to settings and some way to persist the changes in settings. 
Now, after swallowing large amounts of Leo's code, I feel confident enough 
to access all settings data directly in Leo. As far as persistence is 
concerned, I am confident that I can write command to open relevant 
settings file, make change there and save it again. So that part of the 
problem is solvable. The only thing that remains to be done (apart from web 
page) is reloading settings and Edward has created branch for it and 
presumably it will be done in foreseeable future.

Now as I am becoming more and more familiar with Leo's code, implementing 
something in PyQt doesn't seem so frightful anymore. I need to experiment a 
bit.

I wish to implement as a start three very simple dialogs. One for entering 
shortcut, one for entering color and one for entering font. As I write this 
I have just remember that commands `show-fonts` and `show-color-wheel` 
already exists. So it will be just shortcut dialog. It will have just one 
input control which will register any KeyEvent in format that Leo would 
accept for at-shortcuts setting line. When user edits at-color settings 
node, opening color dialog should start with the present color value 
selected and after clicking OK it should change the value in headline. When 
user edits at-font settings node, clicking OK should adjust body of node to 
selected font. When editing line in at-shortcuts node opening shortcut 
dialog should change the relevant line with pressed key combination. In 
more advanced version of shortcut dialog it may present user a list of all 
commands, filter field for filtering commands list and user would be able 
to select command from list and press key combination to be bound to 
selected command.

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: sqlite-leo and collecting settings


>
> When user edits at-font settings node, clicking OK should adjust body of 
> node to selected font. 
>

Done at  30c6dae.
Warning: previously command show-fonts expected that font family is in 
clipboard and it copied selected font family in clipboard after dialog 
confirmation. Now this command doesn't use clipboard but it adjusts body 
changing accordingly not only family but also weight, slant and size  of a 
font.

When invoked outside of at-font node it doesn't do anything special with 
selected font.
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: sqlite-leo and collecting settings

While trying to test new show-fonts capabilities, I have noticed that in 
leoSettings.leo there are just a few at-font settings. However, when 
searching for at-font in Nav panel, it finds tons of settings of the 
following form:

@string  @font-...

It seems that at-font settings kind is replaced with other methods of 
configuration. In the chapter about customizing Leo, there is just one 
paragraph about at-font type of setting and in given example several values 
are set to None. One can't figure by reading that paragraph what can be set 
in _weight, _slant values. Size is maybe obvious but can it be set to 
float? Is it point size or pixel size? 

Is this feature deprecated in favor of something else?

-- 
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.

help with modes and key handling

I have an idea how to allow user to enter shortcut in more natural way: 
just by hitting desired key combination. I don't know how exactly to 
implement it but maybe Edward or Terry would know.

The idea is to create new mode: `input-shortcut`. While in this mode, every 
key combination should lead to one single command `change-shortcut`. This 
command would analyze body line in which cursor is or headline of selected 
node. Assuming in current headline, or current body line there is shortcut 
definition, this shortcut definition gets changed to newly pressed key 
combination, and automatically exits mode `input-shortcut`. I believe this 
command would be easy to write, I just don't know enough how to set this 
new mode and attach handler for it. Maybe for this mode we could use a 
dictionary with default value that lead to `change-shortcut` command. 

If implemented, user could edit at-shortcuts, at-mode, at-button and 
at-command settings (wherever a shortcut is expected) and executing command 
`enter-input-shortcut-mode` and then pressing new key combination. Command 
`change-shortcut` can additionally call c.k.bindKey to make this shortcut 
instantaneously effective and previously defined ineffective. 

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: help with modes and key handling

Command 'edit-shortcut' is in 7142abe.

Usage is like this. When editing line in `@shortcut` node or when `@command 
... @key=` is selected, executing this command will wait for the next key 
combination to be pressed. Whatever key combination user press, that is 
entered in current body line (in case of `@shortcut` node) or in 
appropriate position in headline. It remains to actually bind this key 
combination, which should be easy: one call to `c.k.bindKey`. I'll try to 
add this later this evening. 

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.

new commands for editing fonts, shortcuts,...

Recently I have pushed in master branch on github a few new commands for 
editing certain kinds of settings in more natural way. Command show-fonts 
was changed. In earlier versions this command would show font whose family 
happen to be in clipboard, and after confirming choice Leo used to put 
chosen font family in clipboard, ready to be pasted where appropriate. In 
new version it doesn't take in account content of the clipboard, instead it 
assumes that currently selected node is in fact `@font` setting node. If it 
is, font dialog will show initially font defined by values in the body of 
currently selected node. After confirmation, Leo would adjust body values 
to reflect font that user has chosen. 

Now I am not sure what users expect to happen if show-fonts command is 
invoked not in `@font` node?  What this command should do?

   - give user a warning in Log pane that this command is intended to be 
   executed only when inside `@font` nodes?
   - put chosen font definition in clipboard so that it can be pasted later
   - search outline for the first `@font` node after currently selected 
   node and then operate on that node
   - something else?

A similar situation is with new command `edit-shortcut`. It is supposed to 
be used when editing `@shortcuts` node with shortcuts one per body line, or 
with `@command` node with possible shortcut in headline. What this command 
should do when not in such node?

I plan to tackle also `show-color-wheel` command and make it work with 
currently selected `@color` node. I believe it would be best if all those 
commands are made to give same response in case when currently selected 
node is not of the expected kind. But what that response should be?

Your opinions, please.
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: sqlite-format and settings - ideas


>
> To my surprise, the resulting diff is even worst than I thought it would 
> be: 
> https://github.com/xgid/leo.db-vcs-tests/commit/5648c4ea02c9e1f47efe86ec990fc9aff6554c11?diff=unified
>

Well I am not satisfied with xml diffs either. I believe that it can be 
done by exporting only those features that we care to see diffs of, and in 
smart way so that ordinary text diffs that git (or fossil) calculate give a 
good insight of what really has changed. I have made some initial 
experiments with this idea a while ago. It is on my to-do list and I will 
try to find good way to represent changes that are made using Leo as 
editor. Some fairly simple changes like sorting siblings can give false 
impression of massive changes when in fact there is no big difference in 
code. Those changes should take in to account that editor used was Leo, 
capable of making such changes. Diff tools are made with the assumption 
that editor can either insert lines of code, deletes block of lines or make 
simple change in a line. They can't express any other kind of change like 
moving node from one place to another. One way to deal with it is to keep 
content of every node in git as separate file, and structure of outline in 
a separate text file. When sorting siblings the only change registered 
would be in the order of nodes, and no other changes would be reported in 
diffs. That would however require that external files are not part of git. 
There could be written a special script to re-create all external files 
from separately fetched nodes(bodies and headlnes). That script can be 
hooked with `git clone/fetch/pull` to be executed after any of those 
operations. That script can be minimal Leo distribution or just standalone 
version of leoAtFile and leoFileCommands modules.

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: new commands for editing fonts, shortcuts,...



> Do this if there is no font def in the clipboard.
>
>>
>>- put chosen font definition in clipboard so that it can be pasted 
>>later
>>
>> Yes, if c.p is an `@font node`, the pasting to the clipboard makes sense.
>  
>

Well in current implementation if c.p is an `@font node`, command simply 
adjust body, there is IMHO no need to alter clipboard. 
But if it is not `@font node`, if I understand correctly your advise is to 
put definition in clipboard? It has only one simple drawback that I also 
wanted to reconsider design of `@font node` settings. Currently `@font 
node` has to have in body name of setting repeated several times. For 
example if node is to define 
keyword1_font
it has to have in body 
keyword1_font_family, keyword1_font_weight, keyword1_font_slant and 
keyword1_font_size

It complicates parsing and it leaves more space for typing mistakes. It 
would be better (IMHO), if we put keyword1 in headline, after `@font` and 
in body leave just `family, weight, slant and size`. leoConfig parser can 
deduce full settings names joining name from headline with values in body.

If show-fonts should make definition outside `@font node` and put it in 
clipboard it is name that is not known at that time, and definition from 
clipboard would be useless. If we change syntax of `@font` nodes definition 
in body could be copied and pasted in other nodes without any changes and 
show-fonts could make definition in clipboard ready to be pasted anywhere.

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: sqlite-format and settings - ideas

I wander Edward, what are your thoughts of idea that at least for projects 
using Leo for development it would be advised not to keep external files in 
repository, but instead just to keep nodes as separate text files, named 
after gnx with the content that consist of headline as first line followed 
by content of body. Additionally in repository should be kept special file 
(named after Leo document but with extension `.tree`. This file can contain 
simple representation of tree. Every line starts with number specifying 
level of node and followed by the gnx (and optionally headline for 
readability). Leo can have a command to recreate outline from those pieces 
and also to export pieces in folder. 
A developer (that doesn't use Leo)  interested in such project would have 
to download script which can create all external files defined by Leo 
outline and use those files for whatever purpose he/she likes. If however 
the developer wishes to contribute then another script can parse external 
files and adjust node files. 

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: Rev 79ba3d: potential crasher in refresh-from-disk

@Edward, I have installed pyflakes and enabled those settings the first 
time you suggested me to do so. However, I need to teach myself to pay 
attention to complains of pyflake. I notice them from time to time. Before 
committing I always use git dfiftool to review what changes I am about to 
commit. I must add to this also pyflake re-check. I'll try to be more 
careful in future.
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: Rev 79ba3d: potential crasher in refresh-from-disk

shouldDelete is part of sqlite-leo branch it somehow escaped. I remember 
deleting all those lines but it seems that I haven't saved my changes. 
Sorry about that.
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: new commands for editing fonts, shortcuts,...


>
>
> Such choices are yours to make.
>
O.k. I think warning will do in such cases. 

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: Rev 79ba3d: potential crasher in refresh-from-disk