date:20190915

The beautify and blacken now commands work reliably. The code is in devel.

There are minor differences between them, discussed below.

This page
summarizes all related issues. All open issues are marked "Maybe".

*blacken vs beautify*

Similarities:

- By default, both commands retain underindented comments.
- Both commands ensure that the meaning (parse trees) of body text remains
unchanged.
- Both commands do a much better job of reporting errors than before.
- Both commands are covered by strong unit tests.

Differences:

- The beautify commands do not split or join lines.
The "orange" switch will remain False until further notice.
- There are minor differences in how blacken and beautify format python
slices.
- The beautify commands never regularizes strings.
By default, the blacken commands do not regularize strings.

*Settings*

The defaults are as shown:

@bool beautify-keep-comment-indentation = True
@bool beautify-keep-blank-lines = True

@bool black-keep-comment-indentation = True # Major improvement.
@bool black-string-normalization = False
@int black-line-length = 88

*Summary*

The blacken and beautify commands work well:
- Both commands understand Leonine syntax.
- Both verify that no changes alter the meaning of text.
- Both are covered by strong unit tests.

All open issues beautification issues are marked "Maybe". None will happen
any time soon.

Beautifying source code can become an obsession, but it is of little actual
importance. It's time to move on!

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 view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/8d0ea87c-1d09-4173-aa2f-e646d60926ec%40googlegroups.com.

On vacation for about a week

Rebecca and I will begin a short September trip tomorrow.  We'll be back in 
about a week.

I have just completed the present round of work on the beautify and blacken 
commands.  Here is 
the summary of all the issues.

The work is in devel.  I'll write a post summarizing recent work before I 
leave.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/2494a9f9-d2bc-4fba-a0e8-fb6a4aaafe93%40googlegroups.com.

Re: p.isSelected()

On Sun, Sep 15, 2019 at 8:20 AM vitalije  wrote:

Curiously enough, both: p.setSelected, p.isSelected delegate to
> v.isSelected and v.setSelected. Apart from these delegations no other calls
> to any of these methods is found inside Leo core. I haven't searched for
> them inside plugins and other places. But it seems that Leo would work
> properly even without those methods.
>

I suspect you are correct. What you must not ever do is change any of Leo's
selection methods. They are surprisingly fragile.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1UOz7EZ025XrMOGLbHhYO%2Bo8m13AB%2BsaW9G0uZVTvnGg%40mail.gmail.com.

Re: p.isSelected()

On Sun, Sep 15, 2019 at 1:04 AM Robert Cholette 
wrote:

> Figured it out myself, made it work with this code (trying to set the
> 'selected' property of 'w_ap' if p is the currently selected node):
>

Good work.  I'm not sure I would have been any help.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1qF5Gb505mbQ7g%2B%2BgvmbW9G%2BHk745Ug3WgzH5XniRDqw%40mail.gmail.com.

Re: where are the a="xxx" in leo files?

2019-09-15 Thread Matt Wilkie


>
> It makes sense : marked nodes, along with the currently selected node as 
> the file was saved, are now a 'personal' thing only visible to oneself as 
> they work on a project. makes sense.
>

There is also `@bool put-expansion-bits-in-leo-files = True` which saves 
the tree open/closed state. So you could close all branches except the one 
of interest before saving and sending to friend. It add's noise to source 
code diffs of .leo files but would be helpful in this scenario. Also see 
https://github.com/leo-editor/leo-editor/issues/1022 and 
https://github.com/leo-editor/leo-editor/issues/1023.

True (recommended):
Write "E" attribute bits in  elements.
Leo outlines will record the expansion state of all nodes.

False: (Good for files like unitTest.leo)
Suppress "E" attribute bits in  elements.
Only the ancestors of the presently selected node will
be expanded when Leo opens an outline.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/ba663b36-3a65-4a02-87f4-a1d7a524b30e%40googlegroups.com.

Re: Automatic git commit on save using entr

Ok, thanks for the confirmation. I never close terminal windows and always
launch leo with a command on the command-line.

On Sun, Sep 15, 2019 at 1:48 PM Chris George  wrote:

> I use a .desktop panel shortcut to run Leo. I always run it in a terminal
> window and close the terminal on exit of Leo.
>
>
>
>> Here is where I'm confused. You are launching rerun2 in the background,
>> so it will outlast your bash script for sure. Are you saying you close your
>> console when leo exits and that causes rerun to exit? I run a console with
>> many tabs open. In one tab I launch leo. If I leo exits, I just launch
>> again within the same console instance. With that use case I expect to end
>> up with multiple instances of rerun2.
>>
>> Brian
>>
>
> By using the & after the command in the bash script, the command has been
> detached and runs as a subprocess of the terminal window that is running
> Leo. When I close that terminal the subprocess goes with it. In fact I
> would have to take steps, like disown the subprocess or use nohup to have
> the process continue beyond the closing of the terminal.
>
> HTH,
>
> Chris
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/d825e886-1465-4dbd-a407-d71af4e93763%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CwQ6XMxxPo4qsN9FH%3DVvQc4xSJmVY9Fyq3zFW%3DpFyijmQ%40mail.gmail.com.

Re: Automatic git commit on save using entr

Vitalije,

YMMV, but I had a bad experience with watching files when using Leo. Leo
> often writes files in two phases and it happened to me more than once that
> process watching on files take an empty file or not completely written
> because of this. So, I had to add some latency to watcher.
>

Thanks for the warning, I hadn't thought about that. I just checked my git
history of 321 autocommits over the last 3 weeks of using this setup and in
no cases do I see an empty or partial file being committed. It might be
I've just gotten lucky so far. Or it could also be because the entr utility
has quite a few checks built in. See the Theory of Operation at
http://entrproject.org.

If you precede git command with the '&' g.execute_shell_commands will not
> wait for command to finish


Right. I'm already using the ampersand for launching the long-lived
process. Using it for a short-lived process is worse as with every
execution you are left with a defunct process.

Put this in a node and hit ctrl-b several times:

g.execute_shell_commands(' My pid is $$')


In ps output, you will find a defunct process like this for each one:

[sh] 


So every time I save, I will end up with one of these. The good news with
these is they go away when leo exits.

If I get motivated to improve what I have, I will look into some of your
suggestions regarding Popen and proc.terminate.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CwGi6pOfbAvjZng6QGdH%2BTdw0WPan4gFd6TJd4Vtpj-aQ%40mail.gmail.com.

Re: Automatic git commit on save using entr

2019-09-15 Thread Chris George

I use a .desktop panel shortcut to run Leo. I always run it in a terminal 
window and close the terminal on exit of Leo.

 

> Here is where I'm confused. You are launching rerun2 in the background, so 
> it will outlast your bash script for sure. Are you saying you close your 
> console when leo exits and that causes rerun to exit? I run a console with 
> many tabs open. In one tab I launch leo. If I leo exits, I just launch 
> again within the same console instance. With that use case I expect to end 
> up with multiple instances of rerun2.
>
> Brian
>

By using the & after the command in the bash script, the command has been 
detached and runs as a subprocess of the terminal window that is running 
Leo. When I close that terminal the subprocess goes with it. In fact I 
would have to take steps, like disown the subprocess or use nohup to have 
the process continue beyond the closing of the terminal.

HTH, 

Chris

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/d825e886-1465-4dbd-a407-d71af4e93763%40googlegroups.com.

Re: Automatic git commit on save using entr

Chris,

On Sun, Sep 15, 2019 at 7:11 AM Chris George  wrote:
[...]

> #!/bin/bash
>
> cd ~/leo-editor
> git pull
> cd /working/MEGA/leo-files
> ./rerun2 ./push &
> python3 ~/leo-editor/launchLeo.py $1 $2 $3
>
>
>
Thanks for sharing.

[...rerun2 script...]

At a glance, that script seems to be performing the function of the entr
utility, so 6 one way, half-dozen the other

Since rerun2 is still part of the console session it closes when I close
> Leo which looks after having it hang around clutttering up the joint.
>
>
This might be a little tighter than the method you use.
>

Here is where I'm confused. You are launching rerun2 in the background, so
it will outlast your bash script for sure. Are you saying you close your
console when leo exits and that causes rerun to exit? I run a console with
many tabs open. In one tab I launch leo. If I leo exits, I just launch
again within the same console instance. With that use case I expect to end
up with multiple instances of rerun2.

Brian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CzXFKGCW6f%2BrScJPCkAyY%3DNXyoZMfLFUSfV17VZrZkaSg%40mail.gmail.com.

Re: p.isSelected()

2019-09-15 Thread Robert Cholette

Thank you, indeed comparing a position to commander.p, or as you guys call it, 
c.p, did the trick.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/fc2da498-ada1-48c7-b729-7a6241a79ffc%40googlegroups.com.

Re: Automatic git commit on save using entr

YMMV, but I had a bad experience with watching files when using Leo. Leo 
often writes files in two phases and it happened to me more than once that 
process watching on files take an empty file or not completely written 
because of this. So, I had to add some latency to watcher. That is why I 
came up with my solution using 'save2' handlers, or changing Ctrl-s 
binding. This way you don't need a running process that watches file system 
(which by the way, on some platforms is implemented by constant polling 
file system) and this process wastes some resources too. There is nothing 
to clean up when closing Leo.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/3c36aebd-f090-4266-b648-154a543f1f52%40googlegroups.com.

Re: Automatic git commit on save using entr

Also Popen objects have pid attribute if you need it. And also they have 
methods like terminate or kill. If you want to terminate background process 
on closing Leo, then you need to register handler on 'end1' event which 
should call proc.terminate() on the process you have created with 
subprocess.Popen.
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/a13d3534-dc89-46ed-9ef7-abecf97255f4%40googlegroups.com.

Re: Automatic git commit on save using entr

If you precede git command with the '&' g.execute_shell_commands will not 
wait for command to finish. IOW it will run in the background as you wish. 
You may wish to use subprocess module on your own and starting process with 
subprocess.Popen is fast enough, it won't block your main thread for more 
than a few milliseconds. Git command will run in its own separate process 
and exit after finishing.  Notice that there is no files watching involved, 
there is no need for long running processes either. 

Vitalije

On Sunday, September 15, 2019 at 3:53:33 PM UTC+2, btheado wrote:
>
> Thanks, Vitalije. I had rejected the 'save2' approach because I wanted to 
> run the git commit in the background so it wouldn't add any extra time to 
> the save. Using 'save2' doesn't preclude running the process in the 
> background, but if I take the "naive" approach of using 
> g.execute_shell_commands, then I'm left with the issue of defunct 
> processes (since that function never calls the communicate method for 
> background processes). So I was left with the choice between learning more 
> about Popen and just using the entr utility which I was already familiar 
> with. I chose the latter but that led to the issue of needing to use flock. 
> I may reconsider my choice.
>
> If I do reconsider, then your response will give me a head start on 
> properly using the 'save' hook.
>
>
> On Sun, Sep 15, 2019 at 9:07 AM vitalije > 
> wrote:
>
>> The essential part of the above script is just g.registerHandler('save2', 
>> my_callback). The rest is just for making possible to deactivate handler 
>> and to make every commit with the next natural number. While developing 
>> your handler, it is useful to be able to deactivate it in case of an error. 
>> Also if you change script and run it again it will register another version 
>> of your handler. Quite often, in development, I use the same method to 
>> un-register old version and then register the new one.
>>
>> def reactivate(tag, handler):
>> k = '_activation_%s_handler'%tag
>> # this is just to prevent collisions
>> # you can use whatever string as a key
>> old_handler = c.user_dict.pop(k, None)
>> if old_handler:
>> g.unregisterHandler(tag, old_handler)
>> g.registerHandler(tag, handler)
>> c.user_dict[k] = handler
>> reactivate('save2', my_callback)
>>
>> 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-e...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/630dd216-994f-4a7a-805a-e1b20ed2ae34%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/83ff2275-6b85-4812-9748-04b890daf7e0%40googlegroups.com.

Re: Automatic git commit on save using entr

Thanks, Vitalije. I had rejected the 'save2' approach because I wanted to
run the git commit in the background so it wouldn't add any extra time to
the save. Using 'save2' doesn't preclude running the process in the
background, but if I take the "naive" approach of using
g.execute_shell_commands, then I'm left with the issue of defunct processes
(since that function never calls the communicate method for background
processes). So I was left with the choice between learning more about Popen
and just using the entr utility which I was already familiar with. I chose
the latter but that led to the issue of needing to use flock. I may
reconsider my choice.

If I do reconsider, then your response will give me a head start on
properly using the 'save' hook.

On Sun, Sep 15, 2019 at 9:07 AM vitalije  wrote:

> The essential part of the above script is just g.registerHandler('save2',
> my_callback). The rest is just for making possible to deactivate handler
> and to make every commit with the next natural number. While developing
> your handler, it is useful to be able to deactivate it in case of an error.
> Also if you change script and run it again it will register another version
> of your handler. Quite often, in development, I use the same method to
> un-register old version and then register the new one.
>
> def reactivate(tag, handler):
> k = '_activation_%s_handler'%tag
> # this is just to prevent collisions
> # you can use whatever string as a key
> old_handler = c.user_dict.pop(k, None)
> if old_handler:
> g.unregisterHandler(tag, old_handler)
> g.registerHandler(tag, handler)
> c.user_dict[k] = handler
> reactivate('save2', my_callback)
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/630dd216-994f-4a7a-805a-e1b20ed2ae34%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAO5X8CxTsNnpmw898nxQFUwMjusD5LLfx_f0oqOy8pH2FKnzoA%40mail.gmail.com.

Re: p.isSelected()

It seems that p.isSelected is actually never used in Leo core. Most 
probably it is just a remnant from ancient times.
To get currently selected position you can use c.p, and if you wish to 
check if certain position p is the selected one, use: p == c.p.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4707d100-e3d4-4450-a46c-29c33f4f711c%40googlegroups.com.

Re: Automatic git commit on save using entr

The essential part of the above script is just g.registerHandler('save2', 
my_callback). The rest is just for making possible to deactivate handler 
and to make every commit with the next natural number. While developing 
your handler, it is useful to be able to deactivate it in case of an error. 
Also if you change script and run it again it will register another version 
of your handler. Quite often, in development, I use the same method to 
un-register old version and then register the new one.

def reactivate(tag, handler):
k = '_activation_%s_handler'%tag
# this is just to prevent collisions
# you can use whatever string as a key
old_handler = c.user_dict.pop(k, None)
if old_handler:
g.unregisterHandler(tag, old_handler)
g.registerHandler(tag, handler)
c.user_dict[k] = handler
reactivate('save2', my_callback)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/630dd216-994f-4a7a-805a-e1b20ed2ae34%40googlegroups.com.

Re: Automatic git commit on save using entr