Re: Clones - How To Return To "Original" Node?

[Brian Theado]

Vili,

On Sun, Feb 21, 2021 at 11:58 AM vili  wrote:

> No problem with directories. But, it doesnt work this way on Mac. As I
> pointed out, there is system Python2 preinstalled on Mac by Apple. It is
> called by first row in the "runLeo.py" which reads:
>
> #! /usr/bin/env python
>

If the runLeo.py has the executable bit set and you try executing it
directly, then that first line (commonly called the shebang line) will be
used to execute the file. However if you are invoking python yourself and
passing this runLeo.py file as an argument, then python will ignore that
line because it is a comment. Therefore if you invoke python3 directly,
this line should not be the source of your trouble.

This is the last concrete output you shared related to invoking python3
directly:

vili@Viljems-MBP-2 leo-editor % python3 core/runLeo.py
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3: can't open
file '/Users/vili/leo-editor/core/runLeo.py': [Errno 2] No such file or
directory


As Thomas rightly diagnosed, that error message is telling you that the
file 'core/runLeo.py' does not exist. But you didn't share any details on
what went wrong when you tried with the correct filename.

What error do you get when you run with the correct filename suggested by
Thomas:

cd leo-editor
python3 leo/core/runLeo.py


or since it looks like your leo-editor directory is child of your home
directory, you could run it like this (the tilde expands to your home
directory):

python3 ~/leo-editor/leo/core/runLeo.py


Whatever issue you have with that should have nothing to do with the
shebang line: '#! /usr/bin/env python'.

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/CAO5X8Cxz26f7ecJPQoHNoXnfitNmJrQSiSAQmNwEQJ_FNtBfbw%40mail.gmail.com.

Re: Leo's new unit testing world

[Brian Theado]

Edward,

On Fri, Dec 4, 2020 at 7:40 AM Edward K. Ream  wrote:

> I spent considerable time last week on more complicated schemes for the
> new unit tests. That complexity eventually collapsed. Only create_app
> remains. That collapse would likely not have happened were it not for Brian's
> comment
> :
>
> "I tend to favor composition over inheritance and functions over classes.
> The fixture feature helps with this preference."
>
> Thanks, Brian.
>

I'm glad my comment was helpful.


> Now I see that @test x is precisely equivalent to def test_x. Oh my, I
> have wasted so much time on feeble substitutes for features of python's
> unittest module.\
>

Oh well.  Don't be too hard on yourself :-).


I think the code you have for checking actual vs. expected results is
another opportunity for simplification.

When I change one of the test_editCommands.py expected results in order to
force it to fail and then run it with pytest, I see output like this:

if s1 != s2:  # pragma: no cover
print('mismatch in body')
g.printObj(g.splitLines(s2), tag='expected')
g.printObj(g.splitLines(s1), tag='got')
print('parent_p.b', repr(self.parent_p.b))
>   assert False
E   AssertionError: assert False

leo/unittests/commands/test_editCommands.py:54: AssertionError


This is pytest being helpful and showing exactly where in the code the
failure came from.  Following that output, this is also displayed:

-
Captured stdout call
--
mismatch in body
expected:
[
'first line\n',
'line 1\n',
'line a\n',
'line b\n',
'line cXXx\n',
'last line\n'
]
got:
[
'first line\n',
'line 1\n',
'line a\n',
'line b\n',
'line c\n',
'last line\n'
]
parent_p.b ''


This is your code being helpful by showing more details about how the
actual was different from the expected.

However pytest automatically tries to be similarly helpful if you are more
specific with your assertions.  IOW if you change the code from this:

if s1 != s2:  # pragma: no cover
print('mismatch in body')
g.printObj(g.splitLines(s2), tag='expected')
g.printObj(g.splitLines(s1), tag='got')
print('parent_p.b', repr(self.parent_p.b))
   assert False

to this:

   assert s1 == s2

then the pytest output looks like this:

s1 = self.tempNode.b
s2 = self.after_p.b
>   assert s1 == s2
E   AssertionError: assert 'first line\n...\nlast line\n' == 'first
line\n...\nlast line\n'
E Skipping 56 identical leading characters in diff, use -v to show
E - line c
E + line cXXx
E ?   +++
E   last line


IMO, this is as good if not better than your output. The 'mismatch in body'
message is missing from this, but maybe renaming s1 and s2 to body1 and
body2 would be self-documenting and serve as a suitable replacement.

I get the feeling you are trying to avoid being dependent on pytest
features. But this approach will still be able to run using only unittest,
just that the output won't be as nice.

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/CAO5X8Cys9bUhJvMoArw9k2ohjYJ%3D%3DMkVKB1OhCtq8TnEDUNgtw%40mail.gmail.com.

Re: SB: Please Read. Huge Ahas re unit testing

[Brian Theado]

Having measurable code coverage of the automated tests will be useful.

The coverage.py library is not at all tied to pytest. About a year ago I
tried running its standalone version against Leo's existing tests.

However, some of the coverage results were not making sense. Possibly the
way leo's unit test framework loads the code was causing confusion to
coverage.py. I didn't do any investigation to see if that is a reasonable
guess.

All this to say that your planned approach of extracting the tests into
standard pytests is probably the better path to reliable code coverage
measurements.

Have you considered using pytest features such as fixtures and
parameterized marks?

I tend to favor composition over inheritance and functions over classes.
The fixture feature helps with this preference.

I think your preference is the opposite, but I thought I'd ask.

On Sun, Nov 29, 2020 at 1:52 PM Edward K. Ream  wrote:

> On Sunday, November 29, 2020 at 4:31:42 AM UTC-6 Edward K. Ream wrote:
>
> > The ekr-undo9 branch contains preliminary work on the new testing
> framework.
>
> Not sure that's true. Anyway, work on this topic will be done in the
> ekr-unit-test branch. PR 1762
>  records the work.
>
> After some thought, I've decided to base ekr-unit-test on devel, as usual.
> The goals are to minimize diffs, and to make the unit test work distinct
> from the undo work. When both branches are ready, I'll merge ekr-undo9 into
> devel first, merge devel into ekr-unit-test, and run all the new unit tests.
>
> 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/7debef12-60e1-4463-9dda-8bd6a1ab7dc4n%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/CAO5X8CywWr_fhJsAXh%3DGR-BfSjfdAbQ6ooYpnxmH_UZknNMn0A%40mail.gmail.com.

Re: leo\doc\LeoDocs.leo.orig

[Brian Theado]

This commit on Aug 16th introduced the LeoDocs.leo.orig file:
https://github.com/leo-editor/leo-editor/commit/acd73c59151c9f5304daa4ce08017c6cc7ec3857

I don't see any related PR merge commit, so probably it was pushed directly
to the devel branch without a PR. Git only tracks information about
commits, not pulls and pushes, so it is hard to tell when it was pushed.
That's one way a PR can be useful.

This commit also adds another .orig file:
https://github.com/leo-editor/leo-editor/commit/31ac0645f4c54d16943806f4ed00ac2d02fb6d16

Maybe you want to delete that one also.

George's recommendation about the gitignore file could help prevent future
mistakes like this.

Closely inspecting diffs before making a commit can also help.

Brian

On Mon, Aug 24, 2020 at 4:46 PM Edward K. Ream  wrote:

>
>
> On Mon, Aug 24, 2020 at 3:44 PM George Zipperlen <
> websearch.su...@gmail.com> wrote:
>
> PR #1630 deletes this
>>> file. Edward
>>>
>>
>> Gitignore is your friend.
>>
>
> Right. That's why I said that I would delete or ignore the file. In this
> case, deleting was better, imo, because the file was added by mistake.
>
> 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/CAMF8tS0YXt2VEnqMuU%3DiffJz5Sj%3DAV2U8jBm4HQ2dWR9kDgfCw%40mail.gmail.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/CAO5X8CyukbfOkzSWXfav7sjygvXuxO4Dhrs68UD1k-AxCPKP6w%40mail.gmail.com.

Re: leo stops working

[Brian Theado]

 File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File
> "/home/geoff/anaconda3/lib/python3.7/site-packages/meta/asttools/__init__.py",
> line 55 in 
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 953 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 953 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File
> "/home/geoff/anaconda3/lib/python3.7/site-packages/meta/decompiler/simple_instructions.py",
> line 13 in 
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File
> "/home/geoff/anaconda3/lib/python3.7/site-packages/meta/decompiler/instructions.py",
> line 8 in 
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File
> "/home/geoff/anaconda3/lib/python3.7/site-packages/meta/decompiler/__init__.py",
> line 7 in 
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 953 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   File
> "/home/geoff/anaconda3/lib/python3.7/site-packages/meta/__init__.py", line
> 2 in 
>   File "", line 219 in
> _call_with_frames_removed
>   File "", line 728 in exec_module
>   File "", line 677 in _load_unlocked
>   File "", line 967 in _find_and_load_unlocked
>   File "", line 983 in _find_and_load
>   ...
> Segmentation fault (core dumped)
>
>
>
> On Wednesday, July 29, 2020, 9:53:15 p.m. NDT, Brian Theado <
> brian.the...@gmail.com> wrote:
>
>
> Geoff
>
> On Tue, Jul 28, 2020 at 3:44 PM Geoff Evans 
> wrote:
>
> < pip install leo >   appeared to work (once I banished all the 5.9 stuff
> to a directory outside anaconda), but when I tried to run leo:
>
> (base) geoff:1520>leo mbr.leo
>
> setting leoID from os.getenv('USER'): 'geoff'
> Leo 6.2.1 final
> Segmentation fault (core dumped)
>
>
> For core dumps, you can add 'import faulthandler; faulthandler.enable()'
> to launchLeo.py and you should get a python stack trace at the time of the
> segfault. Maybe you will find a clue in that output. See this thread where
> I share details about doing the same:
> https://groups.google.com/d/msg/leo-editor/ghiIN7irzY0/2wreFgcYDQAJ
>
> Brian
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "leo-editor" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/leo-editor/Y6KRkP5wi2o/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAO5X8CyKFTCuPNUXM8MdafPvo%3D6H%3DDgWGXe%3D8hN58bheRh9pnw%40mail.gmail.com
> <https://groups.google.com/d/msgid/leo-editor/CAO5X8CyKFTCuPNUXM8MdafPvo%3D6H%3DDgWGXe%3D8hN58bheRh9pnw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> 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/1550979585.6600179.1596108273873%40mail.yahoo.com
> <https://groups.google.com/d/msgid/leo-editor/1550979585.6600179.1596108273873%40mail.yahoo.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAO5X8Cw295ROfeuYK-%3DqXECWdqBtRnBn9u_f3COf64ngS7kjBA%40mail.gmail.com.

Re: **Important**: keys branch merged into devel

[Brian Theado]

The git log command I shared shows the diffs for leoSettings in your keys
branch. That didn't help you?

$ git log -p cc568d628 leo/config/leoSettings.leo


Since all the history is still there, you could redo the merge locally
using temporary throwaway branches. For educational purposes, if nothing
else. But also you can use it to see what is different than if you had
resolved the merge conflicts "correctly". What follows is my transcript of
following that advice.

Create the throwaway, temporary branches

$ git branch old-keys cc568d628
$ git branch old-devel 060811435


Run the merge

$ git checkout old-devel
$ git merge old-keys
Auto-merging leo/core/leoGlobals.py
Auto-merging leo/core/leoCommands.py
Auto-merging leo/config/leoSettings.leo
CONFLICT (content): Merge conflict in leo/config/leoSettings.leo
Auto-merging leo/commands/editCommands.py
Automatic merge failed; fix conflicts and then commit the result.


The conflict looks pretty easy to resolve. New vnodes were added in the
same place in both branches. All the new vnodes should be kept

$ git diff leo/config/leoSettings.leo
diff --cc leo/config/leoSettings.leo
index 7c2977cb8,bab3e06d2..0
--- a/leo/config/leoSettings.leo
+++ b/leo/config/leoSettings.leo
@@@ -2321,7 -2319,8 +2321,12 @@@
  @bool outline-tabs-show-close =
True
  
  
++<<<<<<< HEAD
 +
++===
+ 
+ 
++>>>>>>> old-keys
  
  
  If True: Save the Leo file and all modified
derived files every time the external editor saves a modified file.


Since we want to keep all the lines, use vim to remove the "<<<<<",
"=", ">>>>>>" merge conflict cruft:


$ vim leo/config/leoSettings.leo


Commit the merge

$ git add leo/config/leoSettings.leo
$ git commit -m "Merged old-keys into old-devel"


See what changes from the keys branch still aren't in devel. Looks like
there are a few still:

$ git diff devel..old-devel leo/config/leoSettings.leo
diff --git a/leo/config/leoSettings.leo b/leo/config/leoSettings.leo
index 7c01ef527..dac0e2cbf 100644
--- a/leo/config/leoSettings.leo
+++ b/leo/config/leoSettings.leo
@@ -2321,7 +2321,9 @@
 @bool outline-tabs-show-close =
True
 
 
+
 
+
 
 
 If True: Save the Leo file and all modified
derived files every time the external editor saves a modified file.
@@ -3612,19 +3614,25 @@ delete-comments =
Ctrl-parenright # Shift-Ctrl-0
 delete-word = Ctrl-Delete
 delete-word = Keypad+Ctrl+Delete
 delete-spaces   = None
+### NEW:
 indent-region   !text = Tab
-indent-region   = ctrl-greater # Ctrl-shift-
+### OLD:
+# indent-region = Tab # Only when text is selected.
+# indent-region = ctrl-greater # Ctrl-shift-
 kill-line   = Ctrl-k
 kill-to-end-of-line = None
-newline-and-indent  = Ctrl-j
-### newline-and-indent  !text = Tab
+# newline-and-indent= Ctrl-j
+# newline-and-indent!text = Tab
 focus-to-body   !tree = Tab
 paste-text  = Ctrl-v
 reformat-paragraph  = Shift-Ctrl-p
 split-line  = None
 unformat-paragraph  = Shift-Ctrl-u
-unindent-region = ctrl-less # Ctrl-Shift-
-unindent-region = Shift-tab # Only when text is
selected.
+### NEW
+unindent-region !text = Shift-Tab
+# OLD:
+# unindent-region = ctrl-less # Ctrl-Shift-
+# unindent-region = Shift-tab # Only when text is
selected.
 yank= Ctrl-Y
 yank-pop= Alt-Y
 zap-to-character    = Alt-z


Brian

On Sun, Jul 26, 2020 at 12:36 PM Edward K. Ream  wrote:

> On Sun, Jul 26, 2020 at 10:32 AM Brian Theado 
> wrote:
>
> > From https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell,
> "a branch in Git is simply a lightweight movable pointer to one of these
> commits".  So when you delete a branch, you only lose the named pointer to
> the commit. Your merge commit shows which commit the keys branch used to
> point to:
>
> Thanks for this. I'm less alarmed now :-)
>
> However, I am not happy with gitk (or git log) as a means of seeing what
> has happened. Perhaps I am missing something. Yesterday I did discover git
> views, but they haven't helped nearly as much as I would have liked.
>
> And where is the search function in gitk?
>
> 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.

Re: **Important**: keys branch merged into devel

[Brian Theado]

Edward,

On Sun, Jul 26, 2020 at 6:52 AM Edward K. Ream  wrote:
[...]

> P. S. I am alarmed by the potential loss of data when merging git branches.
>
> When I merged the "keys" branch into devel I mistakenly resolved a merge
> conflict by taking devel's version of leoSettings.leo. That was just wrong.
>
> After deleting the "keys" branch, there seems to be no way recover the
> lost key bindings. I would have thought that the git merge would have
> preserved all previous changes to leoSettings.leo, but I was not able to
> see those changes. Fortunately, the required change could easily be deduced.
>
[...]

>From https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell,
"a branch in Git is simply a lightweight movable pointer to one of these
commits".  So when you delete a branch, you only lose the named pointer to
the commit. Your merge commit shows which commit the keys branch used to
point to:

$ git log -n1 818de411e61
commit 818de411e6130086714a2f6bcb97ab52e6182674
Merge: *cc568d628* 060811435
Author: Edward K. Ream 
Date:   Sat Jul 25 08:43:33 2020 -0500

Merge devel into keys, using devel's leoSettings.leo


Before you deleted the keys branch, it pointed to commit cc568d628 and you
can see the changes to leo settings with this command:

$ git log -p cc568d628 leo/config/leoSettings.leo


No commits are lost when you delete a branch.

A pull request from the keys branch into devel would have only helped you
in that it would not have allowed you to merge into the devel branch due to
the merge conflicts. You would have had to resolve the merge conflicts in
the *keys* branch *before* merging into devel. There, one last round of
testing might have exposed the issue, but maybe not. Or maybe inspecting
the diffs one last time through the pull request UI might have helped you
spot the issue. Either way, I don't think a PR provides any extra history
preservation. The commits are all still there.

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/CAO5X8CxHkqZmfW6smQd60pv2HFxG-qP3cwZ%3D9RBCGs9XTprPFg%40mail.gmail.com.

Re: Félix, please give me commit access to leoInteg

[Brian Theado]

Edward,

On Wed, Jul 15, 2020 at 6:24 PM Edward K. Ream  wrote:

> I'd like to push some work to a new branch.
>

Are you familiar with the "fork" workflow of github? Where you can create
a fork of leoInteg in the 'leo-editor' github space and you can push
whatever branch you want. That branch is publicly visible but only in your
fork. If there is something useful you want to merge into Félix's
repository, then you can create a pull request which would allow Feliix to
merge from your forked branch into his repository. On your local leoInteg
git repository, you can have a remote pointing to both his repository and
your fork. That way you can easily merge his latest changes into your
branch.

For the fork workflow you don't need commit access. It would be up to Félix
to decide whether to merge the PR or not.

There are plenty of reasons to prefer direct commit access, but based on
another recent email from you, I had my doubts whether you are fully
familiar with how PRs work. This was the "Should devel be the default
branch?" thread where you wrote:


> I just received and rejected PR #1615
> . This PR was to be
> applied to 6.0-final-rel. That's not how things work. We don't change
> official releases for any reason.
>

> The author does not appear to have commit access, which is troubling.
However, the default branch is "master", not "devel", so perhaps that
explains the situation.

Author's don't need commit access to create pull requests.

HTH,
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/CAO5X8CxT2yTYzqahu7Eg0MUPER6C7G1AYDq6RKjWR%3DPHEaKONQ%40mail.gmail.com.

Re: ENB: Hypothesis might make #1269 feasible

[Brian Theado]

On Fri, May 15, 2020 at 9:39 AM Edward K. Ream  wrote:
[...]

> Here I'll start making the plan more specific. Let's start with the
> following pseudo code, for a new KeyHandlerClass method:
>
>
> def handle_binding(self, event):
> """Handle the given key event."""
> # Use per-state bindings if they exists.
> binding, func = event.binding, None
> if state:
> d = self.state_dict.get(self.state)
> func = d.get(binding) or d.get('default')
> # Otherwise, use per-window bindings.
> if not func:
> d = self.window_dict.get(event.window)
> func = d.get(binding) or d.get('default')
> return func(binding, char)
>

Could you give some examples of various kinds of 'func' and the things they
will do? I can think of two likely flavors. One which performs an actual
action (insert-node, end-of-line, find-next, etc). Another which mainly
just changes self.state. Am I on the right track?

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/CAO5X8CzZ6Okr%3Dq%2BwEgCV5uKVT6vmvJMssSMwiRd8bB%2B1QJrjsA%40mail.gmail.com.

Re: A fix for abbreviations with foreign keyboards is in the #1563 branch

[Brian Theado]

Viktor,

On Sun, May 10, 2020 at 2:22 PM Viktor Ransmayr 
wrote:

> Since it is the first time that I'm trying to work on a Git branch, it
> might well be that the problem is on my side ;-)
>
> The first (strange?) thing I've to report is that after I did a 'git pull'
> - and - tried to do a 'git checkout #1563'  the system responded with
>
> (Leo-Repo) [user@fedora-leo-study-vm leo-editor]$ git checkout #1563
> Your branch is up to date with 'origin/devel'.
> (Leo-Repo) [user@fedora-leo-study-vm leo-editor]$ git branch
> * devel
>   master
> (Leo-Repo) [user@fedora-leo-study-vm leo-editor]$
>
>
In Linux shell, the '#' character indicates the start of a comment, so to
git your command came through as just 'git checkout' and it did nothing.
Try putting quotes around the branch name to keep the shell from seeing it
as a comment:

$ git checkout '#1563'
Branch '#1563' set up to track remote branch '#1563' from 'origin'.
Switched to a new branch '#1563'


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/CAO5X8Cxr4Job6VHtOUQr73-UJpJRN8CJx5PYQOsbnHw0y7WNUA%40mail.gmail.com.

Re: ENB: Qt-prototype is finished

[Brian Theado]

Edward,

On Sun, May 10, 2020 at 8:29 AM Edward K. Ream  wrote:

> Yes that was the idea. Currently I am working on another idea, but it is
>> too soon to share it. I'll write more once I have something to show.
>>
>
> This sounds reasonable. As always, I'll reserve judgment until I see code.
> I eagerly await the next phase of this project.
>
> What is the status of the tree-refresh branch? Is it still relevant?
>

By my understanding, Vitalije's execute_script method integrates the
important parts of tree-refresh branch.

Vitalije,

Can you also add a hypothesis test which instead of executing the random
modification methods one-at-a-time, they get executed via execute_script?
Maybe there are some bugs to shake out there.

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/CAO5X8CybPQtkE1Q8oz9C3KcSQNahtf6X5ZTMO7Dzi1pxHs5vYQ%40mail.gmail.com.

Re: ENB: Qt-prototype is finished

[Brian Theado]

Vitalije,

On Fri, May 8, 2020 at 7:51 AM vitalije  wrote:

> *What next?*
>
> The main purpose of this prototype was to prove my claims about how Leo
> architecture should change. Which parts should be moved to View, which
> should be moved to Model and which should be moved to the Controller.
>
> The classes and methods that belong to VIew are Position, outline
> commands, chapter commands, hoist commands. But how to achieve that.
>
> Let's imagine an object containing all these methods. Each GUI can create
> an object with these methods. QtGUI will return an object much like the
> MyGUI from the prototype. The other GUIs can return an object constructed
> from the current implementation of these commands in Leo. That way those
> other GUIs won't have to change much.
>

Could you explain more on how that would work? The outline commands, for
example, currently live as methods on c. But with your new code they would
be available at c.guiapi.xxx.  The code which currently calls these outline
commands (minibuffer commands and keystroke callbacks?) would be changed to
instead call these c.guiapi.xxx methods? And the wrapper objects on the
other GUIs would make calls to the old methods on c so their old behavior
is retained?

-- 
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/CAO5X8CwxA7PBS-Z6eNkmQuDvnYXRX%3DrJ%3D2LUgLd4qSbsObMCxg%40mail.gmail.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Brian Theado]

It no longer crashes for me, thanks.

While it doesn't crash, it is still possible to move a node left out of a
hoist and the node "disappears". If it is the last node then it
disappears and the outline pane becomes empty. The existing leo doesn't
behave this way. Another behavior difference. Leo doesn't allow a top-level
sibling to be inserted while a node is hoisted. Instead all top-level
insert operations are forced to be child insertions.

Maybe the behavior you have is reasonable, but it doesn't match the way leo
operates.

I'm just pointing these out to let you know. Probably polishing the
prototype is not as important as figuring out how to proceed to see
how/whether it can replace the existing qt gui.


On Sat, May 9, 2020 at 4:48 PM vitalije  wrote:

> Good catch Brian. Revision 8184a2023e5f9 contains the fix for this issue.
> Now hoist/dehoist commands are also tested using hypothesis.
>
> 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/ede74c56-e1b8-44e7-adb5-85a07b9355e8%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/CAO5X8Czv%3DZaFYmV5Y7s3vERTMaD_v98c%2BcHf15phk%3DVXX%2B%2Bt1g%40mail.gmail.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Brian Theado]

Vitalije

On Thu, May 7, 2020 at 2:42 PM vitalije  wrote:

> In last few days I've been working on tests to be sure that all commands
> in new prototype are working correctly and that no crash will ever occur. I
> am pretty sure now that the implementation is correct and there are no
> remaining bugs in the prototype.
>

I added set_hoist to the list of methods randomly called and was able to
get a crash. For me it was a hard-crash with core dump which makes it
harder to find out the scenario causing the crash. It wasn't too hard
though and the steps are simple:

1. hoist any node which has a previous sibling
2. move node right
3. crash:

Traceback (most recent call last):
  File "leo/extensions/myleoqt.py", line 333, in select_item
v = newitem.data(0, 1024)
AttributeError: 'NoneType' object has no attribute 'data'
Fatal Python error: Aborted

Current thread 0x7fad45034740 (most recent call first):
  File "leo/extensions/myleoqt.py", line 1227 in move_just_treeitem
  File "leo/extensions/myleoqt.py", line 1213 in move_treeitem
  File "leo/extensions/myleoqt.py", line 430 in domove
  File "leo/extensions/myleoqt.py", line 449 in make_undoable_move
  File "leo/extensions/myleoqt.py", line 557 in move_node_right
  File "leo/extensions/myleoqt.py", line 1594 in main
  File "leo/extensions/myleoqt.py", line 1597 in 
Aborted (core dumped)


BTW, in order to get the bottom part of the stack trace I added this:

import faulthandler; faulthandler.enable()

-- 
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/CAO5X8CypsUyVwsNXAVxbNzMFi4XsVMP5vZ2-mr8DHo-RLtyW1Q%40mail.gmail.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Brian Theado]

You can try making these changes:

-from hypothesis import given, settings
+from hypothesis import given, settings, Verbosity

-@settings(max_examples=5000, deadline=timedelta(seconds=4))
+@settings(max_examples=5000, deadline=timedelta(seconds=4),
verbosity=Verbosity.verbose)


And then add the '-s' option to the pytest command line so the stdout will
be displayed as the test run.  That will at least give you feedback in the
console if anything is happening. But it make the total runtime of the
tests longer. For me the tests are finishing within two minutes.

I tried the verbose output because I was curious what tests were being run.
Really I wanted to run them with screen updates in between each step so I
could get a visual feel for what the tests are doing. But I haven't
investigated yet to see what I would have to do to force Qt to refresh the
screen.

You could also try setting max_examples really low just as a
baseline-sanity check.


On Sat, May 9, 2020 at 8:15 AM Edward K. Ream  wrote:

> On Friday, May 8, 2020 at 1:42:12 AM UTC-5, vitalije wrote:
>
> > I use pytest for running the tests. Just 'pytest myleoqt.py'.
>
> When I do that a blank python window appears and everything hangs.
>
> I've tried waiting several minutes. What should I do?
>
> 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/0f5bb32d-20a9-49ea-ac86-bdc2b845e4f0%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/CAO5X8Cyfw3fxDUh-qmPhOMbFZbwEktUThb0kmr8fZ_AUNuzdSA%40mail.gmail.com.

Re: ENB: Qt-prototype is finished

[Brian Theado]

Vitalije

On Fri, May 8, 2020 at 7:51 AM vitalije  wrote:

> As Brian suggested in another thread I have changed the strategy for
> performing hypothesis tests. Now test chooses a sequence of commands
> excluding undo and redo commands. After each command if the outline has
> changed, test will check to see if the undo really reverts the effect of
> command and then redo it again. Executing 5000 tests now takes about a
> minute. No bug has been found yet :-).
>

I wasn't necessarily recommending it as a replacement, but just as another
way. Conceivably the two different approaches could uncover different bugs.
But you are the one neck deep in the code and so are the one who can judge
what the best way is.

In order to get the pytest to work I had to save LeoPyRef.leo as
LeoPyRef.db. After that in commit 2560fe96a86, I get passing tests using
pytest. But with latest head (00bda92c), I'm getting error:

___
test_select_and_commnads


@settings(max_examples=5000, deadline=timedelta(seconds=4))
>   @given(data())
def test_select_and_commnads(data):

leo/extensions/myleoqt.py:1488:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _
leo/extensions/myleoqt.py:1490: in test_select_and_commnads
app = demo2_app()
leo/extensions/myleoqt.py:1365: in demo2_app
app.set_c(c)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _

self = , c =


def set_c(self, c):
self.c = c
c.guiapi = self
self.redraw()
item = self.tree.currentItem()
>   self.set_item(item, item)
E   AttributeError: 'MyGUI' object has no attribute 'set_item'

leo/extensions/myleoqt.py:371: AttributeError

-- 
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/CAO5X8Cy%2B8E1BSm0zWUcDNwPB%2B26QzKTSzMmJwyUuwOtUCenWFw%40mail.gmail.com.

Re: Qt-prototype report and some thoughts about executeScript command

[Brian Theado]

Vitalije,

On Thu, May 7, 2020 at 2:42 PM vitalije  wrote:

> First of all I must say that testing with hypothesis is really great way
> to discover hidden bugs. Several bugs were found in the previous
> implementation that are very hard to imagine as a possible scenario. Of
> course most of these bugs were related to clones. Hypothesis did find them
> really quickly and I had to think hard how to solve them. After several
> iterations of running hypothesis and solving found bugs, prototype is now
> able to survive 5000 test sessions. At first I have started each test with
> the complete LeoPyRef.leo outline, test would choose and select a random
> position in this outline, and then it would perform a random sequence of
> commands, checking after each command that both models (v-nodes and tree
> widget items) are in sync. It used to take several minutes for a series of
> 500 tests.
> To speed up tests, I have changed test to use a smaller outline as
> starting position. At start it inserts just five ordinary nodes
> interspersed with five cloned nodes (total of 15 node). Now hypothesis runs
> 5000 tests in about minute. After several executions no bug has been found.
>

That's awesome. A while back when I read about hypothesis property based
testing, I was wondering how to apply it to leo outlines. I knew it would
have to be done either by creating a strategy which could generate
recursive structures or a strategy which could perform sequences of
commands. I didn't see how to proceed. Looks like you nailed it with the
second approach. Nice work!

I looked at the code but I don't understand how to run the hypothesis
tests. I would love to see it in action. Could you share the steps?


> It is highly unlikely that a new bug will be discovered using this test.
> That means we can be pretty sure that no matter what operations and in
> whichever order user executes both models: v-nodes and tree widget items
> will always remain in sync. The outline represented by each of them is
> exactly the same.
>

Have you also considered using the property of random operation + undo =
original tree widget state? And random operation + undo + redo = 2nd state?
I'm not sure that would reveal anything from what you are already testing.
Just a thought.

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/CAO5X8CxszLQDNx%3DxWfUK37DiNXjHQH9r7jnKK-vSiMA2wskYqA%40mail.gmail.com.

Re: A new tree drawing approach

[Brian Theado]

Vitalije,

This looks interesting. Thanks for sharing. I'm not familiar with how the
existing tree drawing approach works. Could you share (in broad strokes)
what the current drawing does and how it is different from your new scheme?

Is it that the existing code recreates all the QT items from scratch every
time there is a redraw? And your code can add/remove a much smaller subset
of QT items because of your set operations?

I didn't quite follow your example about expanding a node. When a node is
expanded, then the children or descendants must appear in the display. How
does that relate to the "set of links" you are using to represent the
outline structure?

Thanks,
Brian

On Tue, Apr 7, 2020 at 9:02 AM vitalije  wrote:

> For several days now, I've been working on a new drawing approach. The
> preliminary results of this work can be seen in the new branch
> tree-refresh .
> There are still some things missing (like hoisting and chapters) but they
> won't be hard to add if Edward accepts this idea.
>
> I had an Aha moment: The outline structure can be represented as a set of
> links, where each link is just a tuple (parent_id, index, child_id). In
> other words, all the information about the structure (or shape) of the Leo
> outline including the information about clones, can be represented by the
> set of elements (parent.gnx, index, child.gnx). And what is more important
> is that obtaining this set from the Leo is not too expensive operation.
>
> import timeit
> def makeset():
> def it(v):
> for i, ch in enumerate(v.children):
> yield v.fileIndex, i, ch.fileIndex
> yield from it(ch)
> return set(it(c.hiddenRootNode))
> g.es(timeit.timeit(makeset, number=100)/100*1000, 'ms')
>
> On my fastest computer this gives 6.14ms for LeoPy.leo. On older computers
> it might be about 12ms.
>
> The idea is to keep track of this set each time we redraw the tree. On the
> next redraw we can simply use the set arithmetic to find what is changed in
> the tree. We calculate new set (let's call it a current_links) and then use
> (current_links - last_links) to get all the inserts and (last_links -
> current_links) to get all deletes.
> Both of these operations are very fast and then we just need to add
> several new links or delete some of the previously existstent links to draw
> new version of tree.
>
> This techinque can eliminate a lot of unnecessary redraws. For example if
> the node is expanded nothing is changed and the only thing necessary is to
> set certain tree item to expanded state.
>
> It isn't only about the speed. There are more benefits of using this
> approach to draw tree. After redrawing the tree, for every position in the
> Leo there exists a single item. This fact alone can make a lot of other
> parts of Leo much simpler. A lot of checks that position exists and is
> still valid may be skipped if the position comes from the tree. Keeping
> track of expanded/collapsed state for each position can be delegated to the
> tree items, because for each valid position there exists a single item.
>
> The code in tree-refresh branch is a prototype that shows this approach as
> possible. It doesn't do hoisting and chapters yet, and the code is not
> cleaned. A lot of qt_tree code is not used and can be deleted. There is one
> more status field in the status line which shows how much time took the
> last redraw. All of the unit tests pass.
>
> There is a room for improvements of diff-calcualtion. In the current
> version bare set difference is used which is not producing the smallest
> possible diff. For example if a parent node has 10 children and we delete
> first one, the difference will contain not just one delete operation as it
> would ideally but 10 deletes followed by 9 inserts, because every child has
> now the different index. Perhaps we can process these differences a bit
> before applying them. But for now it works just fine. Deleting 9 items and
> creating new 9 items is still much less work than deleting the whole
> outline and recreating it from scratch.
>
> 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/945d9bd3-7653-47ba-9617-8359587ae8b5%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 

Re: Opening a theme file doesn't work in Leo 6.1b1

[Brian Theado]

On Sat, Apr 4, 2020 at 2:47 PM Viktor Ransmayr 
wrote:

> At least not for Fedora 30. - See the following traceback I received, when
> I tried to open a theme file!
>
> Traceback (most recent call last):
>
>   File
> "/home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/core/leoCommands.py",
> line 2286, in executeAnyCommand
> return command(event)
>   File
> "/home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/core/leoGlobals.py",
> line 245, in commander_command_wrapper
> method(event=event)
>   File
> "/home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/commands/commanderFileCommands.py",
> line 1025, in open_theme_file
> g.subprocess.Popen(command)
>   File "/usr/lib64/python3.7/subprocess.py", line 800, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib64/python3.7/subprocess.py", line 1551, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] No such file or directory:
> '/home/user/PyVE/PyPI/Leo-stable/bin/python3
> /home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/core/runLeo.py
> "/home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/themes/ZephyrDarkTheme.leo"':
> '/home/user/PyVE/PyPI/Leo-stable/bin/python3
> /home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/core/runLeo.py
> "/home/user/PyVE/PyPI/Leo-stable/lib64/python3.7/site-packages/leo/themes/ZephyrDarkTheme.leo"'
>

 I've never used this command before and I just tried it and I get a
similar error.

https://github.com/leo-editor/leo-editor/commit/016867f5ade5da6796397ab4705287bf8b8f336a
-
this is the commit which fixed #1425 for Windows by using subprocess.Popen
instead of os.system.

The documentation for subprocess.Popen looks complicated:
https://docs.python.org/3/library/subprocess.html and it looks like the
behavior is different for windows and Posix.

"args should be a sequence of program arguments or else a single string or
path-like object. By default, the program to execute is the first item in
args if args is a sequence. *If args is a string, the interpretation is
platform-dependent and described below*"

and

"*Unless otherwise stated, it is recommended to pass args as a sequence*"

So maybe passing as a list rather than string will work for both platforms.
Instead of this:

command = f'{g.sys.executable} {g.app.loadDir}/runLeo.py "{fn}"'


this

command = [g.sys.executable, f"{g.app.loadDir}/runLeo.py", fn]


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/CAO5X8CyYHCStkxe1UJxrUN4p1zxOWdGNQCFUo%3Djm5rtRz6efWg%40mail.gmail.com.

Re: font size shrank

[Brian Theado]

BTW, I meant two finger drag up and down on the mouse trackpad.

On Tue, Mar 31, 2020, 4:26 PM Brian Theado  wrote:

> Are you using leo on a Mac laptop? I've found it easy to accidentally
> change the font size in the body when on Mac. It took me a long time to
> figure out what gesture caused it. If you hold down the Command key and two
> finger drag up and down, the font size will shrink and grow respectively.
> I'm not sure how I manage to "accidentally" make that gesture, but it
> happened to me every few weeks before I finally figured it out.
>
> Thomas' suggestion to re-open the outline would probably also resolve it.
>
> On Tue, Mar 31, 2020 at 2:36 PM andyjim  wrote:
>
>> All was well this morning, but just now when I came back to Leo I find
>> the font size in the bodies of all nodes has shrunk to unreadably small
>> size.  Text in the node headings is ok.  This is only for one of six files
>> I have open. The other five files are as usual.
>> I do not know how to correct this.
>>
>> --
>> 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/8f567309-e221-4d8e-9af0-162be2aa841e%40googlegroups.com
>> <https://groups.google.com/d/msgid/leo-editor/8f567309-e221-4d8e-9af0-162be2aa841e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAO5X8Cw%2BmSQDt9X7Cnp6wEQ1%3DvSGQ0uvXAq-vnGhntCVBgJSCw%40mail.gmail.com.

Re: font size shrank

[Brian Theado]

Are you using leo on a Mac laptop? I've found it easy to accidentally
change the font size in the body when on Mac. It took me a long time to
figure out what gesture caused it. If you hold down the Command key and two
finger drag up and down, the font size will shrink and grow respectively.
I'm not sure how I manage to "accidentally" make that gesture, but it
happened to me every few weeks before I finally figured it out.

Thomas' suggestion to re-open the outline would probably also resolve it.

On Tue, Mar 31, 2020 at 2:36 PM andyjim  wrote:

> All was well this morning, but just now when I came back to Leo I find the
> font size in the bodies of all nodes has shrunk to unreadably small size.
> Text in the node headings is ok.  This is only for one of six files I have
> open. The other five files are as usual.
> I do not know how to correct this.
>
> --
> 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/8f567309-e221-4d8e-9af0-162be2aa841e%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/CAO5X8CzHJaDyf27Pum5L%2BbSKXVyWj0H5CiDuFg1whL%2BP9YZ4Nw%40mail.gmail.com.

Re: New installation log

[Brian Theado]

On Sun, Mar 29, 2020 at 6:09 AM Edward K. Ream  wrote:
[...]

> I am seriously considering ignoring Anaconda and miniconda in Leo's
> installation instructions:
>
> Install python 3
> (ubuntu) apt-get install pip3
> pip install PyQt5
> (optional, if not using git) pip install leo
>

PyQt5 isn't the only requirement for leo. The setup.py file (used by pip)
has all the requirements. Maybe these instructions would be better as it
would get all the dependencies and not just PyQt5:

Install python3
if not using git:

pip install leo

If using git:

git clone 

pip install --editable leo-editor


I haven't personally tested these steps recently, but have done so at one
time or another (using virtual environment).

-- 
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/CAO5X8CwJQN2eHJ8ExABTBwGFJ3r7_c%3DnBy5FCeE%2BWvORvB7U8Q%40mail.gmail.com.

Re: Some excellent pytest articles/presentations

[Brian Theado]

On Mon, Mar 16, 2020 at 6:23 AM Edward K. Ream  wrote:

> When I awoke this morning I understood why you might suggest this. It
> would, supposedly, make it possible to instantiate multiple instances of
> the LeoApp class.  I have just created #1537
>  for this.
>

Thanks. Multiple instances of the class is just one possible benefit of
reduced coupling. I may make a pull request for this and if I do, I will
tag it with #1537.


> As noted in the issue, it's not clear whether changing `g.app` to `self`
> in the LeoApp class would make any real difference. It might well mislead
> people.
>

I agree it is just a drop in the ocean and to me it still makes a
difference. There are always tradeoffs. Is referencing a global variable
rather than self in every single method the best (or even a good) way to
not mislead people about the (current) requirement that LeoApp be a
singleton object? I don't think it is.


> The fact that g.app is a *singleton* instance of the LeoApp class is
> pretty much baked into Leo. For instance, g.app.db is an external file. Do
> we really want to complicate the code by creating a dummy instance of
> g.app.db in some cases?
>

I know there are many other examples of tight coupling throughout leo and
you are just picking g.app.db as one, but for that case leobridge already
uses g.NullObject for g.app.db, so the rest of leo code must already handle
that case.

-- 
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/CAO5X8Cyi0Pr1Nb6vhToOhsLCe4LPnfXKgSSiJy5zoPwDOdyyLw%40mail.gmail.com.

Re: Some excellent pytest articles/presentations

[Brian Theado]

Edward,

On Sun, Mar 15, 2020 at 11:38 AM Edward K. Ream  wrote:

> > the history of re-implementations contains a lot of sad failures.  It's
> just too big a job, the new implementations have their own bugs, and by the
> time they get done, the original version has developed beyond that the new
> one has implemented.
>
> I have no intention of doing a grand reimplementation. However, many of
> Vitalije's suggestions have lead to real improvements.
>
I'll look at all specific suggestions.
>

What do you think about the following specific suggestion?

Change all 'g.app' references in the methods of the LeoApp class to 'self'.
Or add 'app = self' to the method and change 'g.app' to 'app'.


Example diffs for one method:

@@ -1444,57 +1450,61 @@ class LeoApp:
 @cmd('quit-leo')
 def onQuit(self, event=None):
 """Exit Leo, prompting to save unsaved outlines first."""
-if 'shutdown' in g.app.debug:
+app = self
+if 'shutdown' in app.debug:
 g.trace()
-g.app.quitting = True
-if g.app.loaded_session and g.app.sessionManager:
-g.app.sessionManager.save_snapshot()
-while g.app.windowList:
-w = g.app.windowList[0]
-if not g.app.closeLeoWindow(w):
+app.quitting = True
+if app.loaded_session and app.sessionManager:
+app.sessionManager.save_snapshot()
+while app.windowList:
+w = app.windowList[0]
+if not app.closeLeoWindow(w):
 break
-if g.app.windowList:
-g.app.quitting = False # If we get here the quit has been
disabled.
+if app.windowList:
+app.quitting = False # If we get here the quit has been
disabled.


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/CAO5X8Cwq-Lo6zsuQe8ggzdE0Ff6k9%2BBY9jekz3H4qAq7AqCqAQ%40mail.gmail.com.

Some excellent pytest articles/presentations

[Brian Theado]

I came across these articles about pytest recently and thought they might
be of interest to other developers here.

These slides start basic, but cover a lot of ground and I learned a lot:
https://nedbatchelder.com/text/test3.html

Not the main thrust of the presentation, but one quote I liked:

"The kind of change I’m talking about here is refactoring your product code
so that your tests can get at the parts they want to. There’s nothing wrong
with using your testing as a way to challenge the modularity of your code.
Usually, improving the structure to benefit tests also ends up helping you
in other ways."


Another quote I found useful. Based on this explanation, I changed some
tests I happened to be writing at the time (i.e moving more code out from
the test and into fixtures). Having the error vs. failure distinction is
useful in troubleshooting failed tests:

"Exceptions in the fixtures are counted as Errors, whereas exceptions in
the test function are Failures. This is a subtle but important distinction.
A Failure means the test ran, and detected a problem in the product code.
An Error means we couldn’t run the test properly.

This distinction is one reason to put set-up code in fixtures, but there
are others as we’ll see."

The below two were linked from the above presentation:

https://salmonmode.github.io/2019/03/29/building-good-tests.html

This article also had some snips related to the quotes I already pasted
above (emphasis mine):

"Testing code should not be difficult. *If the code is hard to test, then
the code is hard to use*. This is also indicative of tightly coupled code."


"Steps in the setup process can be broken out into standalone fixtures that
should throw errors if something didn’t go well. When those errors are
thrown, they will show up as an error in the test report, rather than a
failure in the test itself. When a test has an error, it should represent
that the desired state for that test could not be reached. If a test fails,
it should represent that the state was reached, but something about the
state is wrong"


https://github.com/okken/pycascades2020 - Multiply your Testing
Effectiveness with Parametrized Testing

I haven't gone through this one as thoroughly, but it also seems pretty
good.

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/CAO5X8CzCmrC5qJuDSXSfFXLDjhOhSHvYTp%3DEuw6ZDa4gAGFGng%40mail.gmail.com.

Re: How To Intercept Clicks On Links in a QT5 Browser Widget

[Brian Theado]

On Wed, Feb 26, 2020 at 11:05 PM Thomas Passin  wrote:

> Thanks!  Wow, that will save me lots of time.  U, I don't see how to
> "paste as node".  My version of Leo has no menu item or leo command that
> seems to be that.  Of course I can just paste it into the body of a node,
> but that won't give the same result.
>

Looks like you already got it working, but the menu pick is at
Outline->Paste-Node. Ctrl-Shift-v is the default keybinding.

-- 
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/CAO5X8CzLBtBhgZTViefd7x%3D6t5O--AjONQHLMSsDjicBLBoOCg%40mail.gmail.com.

Re: How To Intercept Clicks On Links in a QT5 Browser Widget

[Brian Theado]

Thomas,

Below I've pasted a leo subtree containing a demo @button which will
display html hyperlinks to nodes inside a QTextBrowser.

To use it copy the xml and in a leo outline, "paste as node". Create a
script button from it and after clicking the button, a new pane should
appear containing hyperlinks to the selected node and each of its subtree
nodes. Clicking on those hyperlinks will move the selection to the node
corresponding to the clicked link.

QT dock-based display only.

I thought I'd share in case it helps you along with what you are doing. The
code is a little rough around the edges, but since it is a complete working
example, it might be useful to you.



http://leoeditor.com/namespaces/leo-python-editor/1.1;
>


@button node linked html
display_widget_in_leo_pane()
display_html
node_link
display_node_linked_html



@language python
from PyQt5 import QtCore, QtWidgets
@others

# Just some sample node links, one on each line
html = "\n".join([
node_link(p) + "br/"
for p in p.self_and_subtree()
])

# Display the html in a docked widget
display_node_linked_html(c, html)

def display_widget_in_leo_pane(g, c, w,
name):
"""
w is the widget to display
name is the name the widget should appear in pane menu
"""
dw = c.frame.top
c.user_dict.setdefault('btheado_docks', {})
dock_dict = c.user_dict['btheado_docks']
dock = dock_dict.get(name)
if not dock:
dock = g.app.gui.create_dock_widget(
 closeable=True, moveable=True, height=50, name=name)
dock_dict[name] = dock
dw.addDockWidget(QtCore.Qt.RightDockWidgetArea, dock)
dock.setWidget(w)
dock.show()
#g.es(dock.widget())

def display_html(html, name = 'test
html'):
w = QtWidgets.QTextBrowser()
w.setHtml(html)
display_widget_in_leo_pane(g, c, w, name)
return w
def display_node_linked_html(c, html):
def link_clicked(url):
if url.isRelative():
if url.path().startswith('node/'):
gnx = url.path().split("/")[-1]
target = next((
p
for p in c.all_unique_positions()
if p.v.gnx == gnx
), None)
if target:
w.setSource(QtCore.QUrl())
c.selectPosition(target)
# Without this, there is possibility of the
# position not being displayed and subsequent
# expand of the node not showing all descendants
c.redraw()
else:
g.es(f"Could not find node with gnx: {gnx}")
else:
g.es(f"Don't know how to handle url: {url.toString()}")
else:
g.es(f"Don't know how to handle url: {url.toString()}")

w = display_html(html)
w.anchorClicked.connect(link_clicked)
def node_link(p):
return f"""
a style="color: violet; text-decoration: none;"
href="node/{p.v.gnx}"{p.h}/a
"""




On Wed, Feb 26, 2020 at 12:45 PM Thomas Passin  wrote:

> If I create a QT5 browser widget, and (within Leo) want to intercept and
> act on clicks on hyperlinks, is that feasible?  Would I just look up the
> event for a hyperlink click and connect it to my own handler?
>
> What I'm interested in specifically is the case where I have a mind map in
> the browser, and I want the links to go to corresponding nodes in a Leo
> outline.  It would seem that handling the click would be easier than trying
> to use the Leo Bridge (which I'm totally ignorant of).
>
> --
> 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/500414ec-9e4b-4bfa-bb62-f763de2be5d6%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/CAO5X8Cx35cRLoF%2BW_b_kZurxY7nPGbwVkZY%2BZPc95XQv0yqHCg%40mail.gmail.com.

Re: zombie process generated by g.execute_shell_commands

[Brian Theado]

This is working fine for me now. I don't see zombie processes for the
exited background commands anymore. Nice work.

On Sun, Feb 9, 2020 at 8:07 AM Edward K. Ream  wrote:

> On Sunday, February 9, 2020 at 6:08:42 AM UTC-6, Edward K. Ream wrote:
>
> > I have just created #1489
>  for this topic.
>
> Rev 98530b0
> 
> in devel attempts a fix. I'm not sure it actually does anything useful.
> Please reopen if problems remain, or if you have other suggested fixes.
>
>
> 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/e81a0a75-f12e-48ea-9bb3-0f81c447df95%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/CAO5X8CyAVyKbeiLVxOB1JO_H28%2BR8zcg3qnNRjT8o2bkuSNnBQ%40mail.gmail.com.

Re: zombie process generated by g.execute_shell_commands

[Brian Theado]

On Sat, Feb 8, 2020 at 4:41 AM Edward K. Ream  wrote:

> On Thu, Feb 6, 2020 at 1:08 PM Xu Wang  wrote:
>
>> Dear Leo Developer,
>>
>> I created one button in Leo, the corresponding script is:
>>
>> c.save()
>> g.execute_shell_commands(['git -C /Users//leodata add austin.leo',
>> 'git -C /Users//leodata commit -mupdates', ' -C /Users//leodata
>> push'])
>>
>>
>> Basically, it will save the changes and do a git add/commit/push.
>>
> [...]

> Do I need to do something extra in g.execute_shell_commands ?
>>
>
> Good question. Sometimes Leo appears to hang (on Windows) after running
> unit tests with g.execute_shell_commands. For me, a fix is to type a
>  in the console from which Leo is running.
>
> I'm not sure what else can be done. The guts of g.execute_shell_commands
> is just:
>
> proc = subprocess.Popen(command, shell=True)
> if wait: proc.communicate()
>
> You could try experimenting with shell=False, but I doubt that will work.
>

Here is a thread from last year on the same topic:
https://groups.google.com/d/msg/leo-editor/1VOYPUJrNEM/ItZwstC0AwAJ. In my
emails there, I was assuming that running short-lived processes in the
background will inevitably lead to zombies and I so I shared a workaround
of doing the git commits with a long-running background process.

But now I just noticed the subprocess oabjects have a poll method (
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.poll).
Maybe if g.execute_shell_commands is called with 'not wait', then leo
should save the proc object and at idle time make a call to proc.poll for
it (and any other launched background tasks). Then at the next idle call
proc.poll again. Keep doing that until proc.poll doesn't return None.

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/CAO5X8CyapLuNrzoQrtu9fsP-pXzdVuqBF4PmtPjypEBejZMwyQ%40mail.gmail.com.

Re: pytest coverage testing is a wow

[Brian Theado]

On Thu, Jan 16, 2020 at 4:20 PM Edward K. Ream  wrote:
[...]

> The test_one_line_pet_peeves function contains a table of snippets. Modulo
> some housekeeping, it is:
>
> for contents in table: # table not shown. Some tests in the table fail.
> contents, tokens, tree = self.make_data(contents, tag)
> expected = self.blacken(contents)
> results = self.beautify(contents, tag, tokens, tree)
> if results != expected:
> fails += 1
> assert fails == 0, fails
>
> *All the "one-line tests" run, even if some fail.*
>
>
It's also convenient to "pretend" that the test passes even when it
> doesn't. That way the -x (fail fast) option doesn't bother us.  So, for
> now, the last line is:
>
> assert fails == 13, fails
>
> As I fix the unit test failures I'll decrease the error count.
>

It is possible to let pytest do the bookkeeping for you by using a pytest
decorator to parameterize the test. See
https://docs.pytest.org/en/latest/parametrize.html.

Also, the @pytest.mark.xfail decorator (
https://docs.pytest.org/en/latest/skipping.html#xfail-mark-test-functions-as-expected-to-fail)
is useful for "a bug not yet fixed" which sounds like what you are
describing.

The parameterize decorator supports marking the input arguments with xfail
independent of each other.

-- 
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/CAO5X8CzOBi0G%3DRxJFfUqpXjAx4DxSJs70sXSxeBxajs6tg1a1Q%40mail.gmail.com.

More Python parsing libraries

[Brian Theado]

I was looking up mutation testing libraries for python and came across
several references to Python parsing which I thought in light of recent
work, Edward would be interested in. Mutation testing deserves its own
thread. Here I'm just sharing the parsing references.

The mutation testing library and related article is at
https://pypi.org/project/mutmut/ and
https://hackernoon.com/mutmut-a-python-mutation-testing-system-9b9639356c78.
The article has this bit (emphasis mine):

"I decided that I absolutely wanted a feature both Cosmic Ray and mutpy
lacked: being able to apply a mutation on a source file and not screw up
the entire file. Cosmic Ray and mutpy* use Pythons built in AST library but
it has the unfortunate property of not representing formatting in the AST,
making it impossible to just dump the AST back out and get the original
file*. So if I can’t use Pythons own AST, what then? Enter baron
, an independently developed Python->AST
library specifically created to be able to round trip without changing your
source files. Baron doesn’t support all of Python 3 syntax yet
unfortunately, but it looks like people are working on it.
[EDIT: Since this article *I’ve replaced Baron with Parso* and now I fully
support Python 3!]"


https://github.com/PyCQA/baron

"Baron is a Full Syntax Tree (FST) library for Python. By opposition to an
AST  which drops some
syntax information in the process of its creation (like empty lines,
comments, formatting), a FST keeps everything and guarantees the
operation fst_to_code(code_to_fst(source_code))
== source_code."


https://parso.readthedocs.io/en/latest/

"Parso is a Python parser that supports error recovery and *round-trip
parsing* for different Python versions (in multiple Python versions). Parso
is also able to list multiple syntax errors in your python file."


https://github.com/davidhalter/jedi - not related to parsing, but it uses
parso. Dropping the link leo being an editor might be able to make use of
it:

"Jedi is a static analysis tool for Python that can be used in
IDEs/editors. Jedi has a focus on autocompletion and goto functionality.
Jedi is fast and is very well tested. It understands Python and stubs on a
deep level."

-- 
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/CAO5X8Cyt_r4N1t%3DVgpYpbcZBfftB3%3DpvTpMks5oMt0zh9kqaZw%40mail.gmail.com.

Re: Please review the new docs for #1440

[Brian Theado]

On Wed, Jan 15, 2020 at 3:57 AM Edward K. Ream  wrote:

> On Tue, Jan 14, 2020 at 7:06 PM Brian Theado 
> wrote:
>
[...]

> The ast module is particularly deficient in this regard. The documentation
> for  ast.walk <https://docs.python.org/3/library/ast.html#ast.walk> is:
>
> " Recursively yield all descendant nodes in the tree starting at *node*
> (including *node* itself), in no specified order. This is useful if you
> only want to modify nodes in place and don’t care about the context."
>
> Hmm. This could be one motivating example. The TOG class inserts
> parent/child links, and TOT.traverse(tree) *is* the token order
> traversal. So a much more valuable version of ast.walk would be:
>
> tog = TokenOrderGenerator()
> tot = TokenOrderTraverser()
> contents, encoding, tokens, tree = tog.init_from_file(filename)
> tot.traverse(tree)
>

But in its current form, this example doesn't do anything user visible. It
doesn't return anything and it doesn't display anything. IMO, examples
should as much as possible be standalone and do something the user can see.
That way the user can paste the exact code into a REPL and see something
happen. Or better, the documentation showing the example can also show the
results.

As it is now, the user would have to define a subclass of TOT in order to
see anything. This is what I was complaining about in another thread. In
order to be usable, at a minimum a 5 line subclass needs to be written. I
proposed that you move the logic from that class into a function which
yields each result. That function could be used both by the TOT class and
by simple for loops (perfect for demo and explanations).

But your response was "You have little chance of changing my mind" :-).
Maybe my suggestion isn't the right approach, but I still think there is
something missing regarding ease-of-use.

[...]

> The injected links will be useful for any tool that wants to modify python
> source code. fstringify and black are two most prominent examples.  Now we
> come to the real motivation. This is the "hole" in the documentation I have
> been talking about.
>
> *Any* tool that wants to modify python text will benefit from having
> *both* a token-level view of the text *and* a parse-tree level view of
> the text. The asttokens package provides this dual view, but only for
> top-level python statements. In effect, the TOG class is a much simpler
> implementation of the asttokens package.
>
> This suggests that some wrapper functions, similar/identical to those in
> the asttokens package, would be useful.
>

If this means you will be able to write simple examples in the form of the
one on the front page of the asttokens package, then it sounds useful.

[...]

Thanks for all the other explanation.

-- 
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/CAO5X8CzfYaG-a3xjN%3DJw_4Az9jSo63BWRe9uk753h%2BxErgOeiQ%40mail.gmail.com.

Re: Please review the new docs for #1440

[Brian Theado]

I like your second comment
<https://github.com/leo-editor/leo-editor/issues/1440#issuecomment-573661883>.
It is well written and informative. Nice job.

You stress "token order traversal".  How does that contrast the traversal
provided by the ast library? Does your library still traverse the ast nodes
in the same order as the ast library does, just that with each visited node
you will have access to all the tokens corresponding to that node?

Back to the first comment:

A *children* array from each ast node to its children. Order matters!


In contrast, how does the ast library link the ast nodes? Not at all?
Linked, but out of order? Something else?

And this:

   - For each token, *token.node* contains the ast.node "responsible" for
   the token.
   - For each ast node, *node.first_i* and *node.last_i* are indices into
   the token list.
   These indices give the range of tokens that can be said to be
   "generated" by the ast node.

Does this imply the user can choose between traversing each token (and from
the token reach the node) and traversing each node (and from the node reach
each token)? In what case would the user want to do one over the other?


On Tue, Jan 14, 2020 at 7:06 PM Brian Theado  wrote:

> In the theory of operation:
>
> "The notion of a *token order traversal* of a parse tree is the
> foundation of this project"
>
> In contrast, what traversal order do parse trees provide? How is token
> order different/better? What does it allow me to do that I can't otherwise
> do with parse trees?
>
> "This help is essential, because the following two source files generate
> identical parse trees!"
>
> This implies to me that with a parse tree you can't do a round trip from
> source code, to a parse tree and back to the original source code. Is that
> correct? If so is this just one externally visible benefit to your library
> or is it the main benefit? If it is the main benefit, then I think it
> should be made much more clear earlier in the document like in the Overview
> near here:
>
> "These links promise to collapse the complexity of any code that changes
> text, including the asttokens <https://pypi.org/project/asttokens/>,
> fstringify <https://pypi.org/project/fstringify/>, and black
> <https://pypi.org/project/black/> projects."
>
> something like:
>
> "These links allow portions of python source code to be transformed while
> leaving the rest untouched. Much of the complexity of the asttokens
> <https://pypi.org/project/asttokens/>, fstringify
> <https://pypi.org/project/fstringify/>, and black
> <https://pypi.org/project/black/> projects comes from not being able to
> link between the text and structure of the Python code.  Using the code of
> this library can collapse the complexity of these and any projects which
> change Python text"
>
> On Tue, Jan 14, 2020 at 6:10 PM Brian Theado 
> wrote:
>
>> Ok, now I see in your proposed email response in the other thread you do
>> mention the asttokens project. And also later in #1440 you said "The
>> asttokens <https://asttokens.readthedocs.io/en/latest/> project assigns
>> tokens to ast nodes, but only for statement-level ast nodes." That's useful
>> to know.
>>
>> One thing I really like about the front page of that project (
>> https://github.com/gristlabs/asttokens) is the front-and-center example
>> which shows in a few lines of code how to call the code using concrete
>> inputs and shows exactly what the outputs are.
>>
>> I find that very valuable. Examples are usually the first thing I want to
>> see. Can you have something similar in #1440?
>>
>> On Tue, Jan 14, 2020 at 5:59 PM Brian Theado 
>> wrote:
>>
>>> I just followed the stackoverflow link (
>>> https://stackoverflow.com/questions/16748029/how-to-get-source-corresponding-to-a-python-ast-node#)
>>> and someone posted that they created
>>> https://github.com/gristlabs/asttokens which "Annotates Python AST
>>> trees with source text and token information". Is that different from
>>> what your code does?
>>>
>>> On Tue, Jan 14, 2020 at 8:02 AM Edward K. Ream 
>>> wrote:
>>>
>>>> In a day or three I'll be announcing #1440
>>>> <https://github.com/leo-editor/leo-editor/issues/1440>, the
>>>> unification of parse trees and tokens, to python's core developers.  I'll
>>>> do that by making a comment in this related python issue
>>>> <https://bugs.python.org/issue7>.
>>>>
>>>> In preparation for that announcement, I have revised/created the firs

Re: Please review the new docs for #1440

[Brian Theado]

In the theory of operation:

"The notion of a *token order traversal* of a parse tree is the foundation
of this project"

In contrast, what traversal order do parse trees provide? How is token
order different/better? What does it allow me to do that I can't otherwise
do with parse trees?

"This help is essential, because the following two source files generate
identical parse trees!"

This implies to me that with a parse tree you can't do a round trip from
source code, to a parse tree and back to the original source code. Is that
correct? If so is this just one externally visible benefit to your library
or is it the main benefit? If it is the main benefit, then I think it
should be made much more clear earlier in the document like in the Overview
near here:

"These links promise to collapse the complexity of any code that changes
text, including the asttokens <https://pypi.org/project/asttokens/>,
fstringify <https://pypi.org/project/fstringify/>, and black
<https://pypi.org/project/black/> projects."

something like:

"These links allow portions of python source code to be transformed while
leaving the rest untouched. Much of the complexity of the asttokens
<https://pypi.org/project/asttokens/>, fstringify
<https://pypi.org/project/fstringify/>, and black
<https://pypi.org/project/black/> projects comes from not being able to
link between the text and structure of the Python code.  Using the code of
this library can collapse the complexity of these and any projects which
change Python text"

On Tue, Jan 14, 2020 at 6:10 PM Brian Theado  wrote:

> Ok, now I see in your proposed email response in the other thread you do
> mention the asttokens project. And also later in #1440 you said "The
> asttokens <https://asttokens.readthedocs.io/en/latest/> project assigns
> tokens to ast nodes, but only for statement-level ast nodes." That's useful
> to know.
>
> One thing I really like about the front page of that project (
> https://github.com/gristlabs/asttokens) is the front-and-center example
> which shows in a few lines of code how to call the code using concrete
> inputs and shows exactly what the outputs are.
>
> I find that very valuable. Examples are usually the first thing I want to
> see. Can you have something similar in #1440?
>
> On Tue, Jan 14, 2020 at 5:59 PM Brian Theado 
> wrote:
>
>> I just followed the stackoverflow link (
>> https://stackoverflow.com/questions/16748029/how-to-get-source-corresponding-to-a-python-ast-node#)
>> and someone posted that they created
>> https://github.com/gristlabs/asttokens which "Annotates Python AST trees
>> with source text and token information". Is that different from what
>> your code does?
>>
>> On Tue, Jan 14, 2020 at 8:02 AM Edward K. Ream 
>> wrote:
>>
>>> In a day or three I'll be announcing #1440
>>> <https://github.com/leo-editor/leo-editor/issues/1440>, the unification
>>> of parse trees and tokens, to python's core developers.  I'll do that by
>>> making a comment in this related python issue
>>> <https://bugs.python.org/issue7>.
>>>
>>> In preparation for that announcement, I have revised/created the first
>>> three comments of #1440:
>>>
>>> - The first (main) comment
>>> <https://github.com/leo-editor/leo-editor/issues/1440> gives an
>>> overview of the project and its status.
>>> - The second comment
>>> <https://github.com/leo-editor/leo-editor/issues/1440#issuecomment-573661883>
>>> is the Theory of Operation.
>>> - The third comment
>>> <https://github.com/leo-editor/leo-editor/issues/1440#issuecomment-574145510>
>>> contains the Project's history.
>>>
>>> The announcement itself will be fairly brief, and will refer readers to
>>> #1440 for more details. So I want these three comments to be "perfect".
>>>
>>> Please read and critique all three comments.  I am interested in your
>>> comments and suggestions.
>>>
>>> Edward
>>>
>>> P. S. There are similar discussions in LeoDocs.leo, but I'll be
>>> referring to #1440 in the upcoming public announcements. The links above
>>> are good looking and are available to anyone, including those with no
>>> access to Leo.
>>>
>>> EKR
>>>
>>> --
>>> 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 v

Re: Discuss: a proposed answer to python issue #33337

[Brian Theado]

On Tue, Jan 14, 2020 at 4:05 PM Edward K. Ream  wrote:

> On Tue, Jan 14, 2020 at 3:00 PM Terry Brown  wrote:
>
>> I wonder if a couple of demos would help,
>>
>
> Thanks for this suggestion.  Imo, the demo is the TOG class compared with
> similar code in asttokens, fstringify and black. The differences are
> striking.
>

This puts the burden on all the readers to go look at the two versions of
fstringify (and other) code and be able to figure out on their own exactly
what striking differences you are referring to. If you do the work to
present the differences in an easy to read way, then all readers will
benefit. Are there small pieces you can put side-by-side which show the
improvements? But that's extra work you may not want to do and maybe it is
hard to do. I'm just sharing my thoughts.

-- 
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/CAO5X8Cz%3DM3b4sJDerTwy%2BfmFPs_xDeSDrrXhr2XgDjvzS1BVLg%40mail.gmail.com.

Re: Please review the new docs for #1440

[Brian Theado]

Ok, now I see in your proposed email response in the other thread you do
mention the asttokens project. And also later in #1440 you said "The
asttokens <https://asttokens.readthedocs.io/en/latest/> project assigns
tokens to ast nodes, but only for statement-level ast nodes." That's useful
to know.

One thing I really like about the front page of that project (
https://github.com/gristlabs/asttokens) is the front-and-center example
which shows in a few lines of code how to call the code using concrete
inputs and shows exactly what the outputs are.

I find that very valuable. Examples are usually the first thing I want to
see. Can you have something similar in #1440?

On Tue, Jan 14, 2020 at 5:59 PM Brian Theado  wrote:

> I just followed the stackoverflow link (
> https://stackoverflow.com/questions/16748029/how-to-get-source-corresponding-to-a-python-ast-node#)
> and someone posted that they created
> https://github.com/gristlabs/asttokens which "Annotates Python AST trees
> with source text and token information". Is that different from what your
> code does?
>
> On Tue, Jan 14, 2020 at 8:02 AM Edward K. Ream 
> wrote:
>
>> In a day or three I'll be announcing #1440
>> <https://github.com/leo-editor/leo-editor/issues/1440>, the unification
>> of parse trees and tokens, to python's core developers.  I'll do that by
>> making a comment in this related python issue
>> <https://bugs.python.org/issue7>.
>>
>> In preparation for that announcement, I have revised/created the first
>> three comments of #1440:
>>
>> - The first (main) comment
>> <https://github.com/leo-editor/leo-editor/issues/1440> gives an overview
>> of the project and its status.
>> - The second comment
>> <https://github.com/leo-editor/leo-editor/issues/1440#issuecomment-573661883>
>> is the Theory of Operation.
>> - The third comment
>> <https://github.com/leo-editor/leo-editor/issues/1440#issuecomment-574145510>
>> contains the Project's history.
>>
>> The announcement itself will be fairly brief, and will refer readers to
>> #1440 for more details. So I want these three comments to be "perfect".
>>
>> Please read and critique all three comments.  I am interested in your
>> comments and suggestions.
>>
>> Edward
>>
>> P. S. There are similar discussions in LeoDocs.leo, but I'll be referring
>> to #1440 in the upcoming public announcements. The links above are good
>> looking and are available to anyone, including those with no access to Leo.
>>
>> EKR
>>
>> --
>> 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/5c6da99b-360f-4ab2-bae9-f9a4d589e860%40googlegroups.com
>> <https://groups.google.com/d/msgid/leo-editor/5c6da99b-360f-4ab2-bae9-f9a4d589e860%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAO5X8CwBaxpjgiRnqdyzFZK2MKr7Pq1bLivL5iDhtMETHOhNLA%40mail.gmail.com.

Re: Please review the new docs for #1440

[Brian Theado]

I just followed the stackoverflow link (
https://stackoverflow.com/questions/16748029/how-to-get-source-corresponding-to-a-python-ast-node#)
and someone posted that they created https://github.com/gristlabs/asttokens
which "Annotates Python AST trees with source text and token information".
Is that different from what your code does?

On Tue, Jan 14, 2020 at 8:02 AM Edward K. Ream  wrote:

> In a day or three I'll be announcing #1440
> , the unification
> of parse trees and tokens, to python's core developers.  I'll do that by
> making a comment in this related python issue
> .
>
> In preparation for that announcement, I have revised/created the first
> three comments of #1440:
>
> - The first (main) comment
>  gives an overview
> of the project and its status.
> - The second comment
> 
> is the Theory of Operation.
> - The third comment
> 
> contains the Project's history.
>
> The announcement itself will be fairly brief, and will refer readers to
> #1440 for more details. So I want these three comments to be "perfect".
>
> Please read and critique all three comments.  I am interested in your
> comments and suggestions.
>
> Edward
>
> P. S. There are similar discussions in LeoDocs.leo, but I'll be referring
> to #1440 in the upcoming public announcements. The links above are good
> looking and are available to anyone, including those with no access to Leo.
>
> EKR
>
> --
> 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/5c6da99b-360f-4ab2-bae9-f9a4d589e860%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/CAO5X8CxyBP_X72L-_b4xj4AxAcoZEA27-R%3Dz0ZONUeRfk34Yow%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

Oops accidentally hit send when I was pasting in the two examples. Here is
the other one:

else:
# Some fields contain ints or strings.
assert isinstance(z, (int, str)), z.__class__.__name__

On Sun, Jan 12, 2020 at 9:49 AM Brian Theado  wrote:

>
> On Sun, Jan 12, 2020 at 8:18 AM Edward K. Ream 
> wrote:
>
>>
>>
>> On Sat, Jan 11, 2020 at 2:11 PM Brian Theado 
>> wrote:
>>
>> > I have doubts about the following entries you are suppressing: assert,
>> except, raise.
>>
>> Imo, they are fine.  Assert signal that something is seriously wrong
>> with the tool, not the user input.
>>
>
> My suggestion was to allow coverage to report on execution of assert
> statements. It sounds to me like you are responding as if I suggested to
> test assertion failures. Code coverage reporting can't distinguish between
> when the assertion fails and when it doesn't.
>
> I only found 2 instances of assert statements not being covered when I
> change .coveragerc to include asserts and re-ran the tests. In both cases
> they are else clauses which your current tests don't cover.
>
> if e is not None: assert e.lower() == 'utf-8', repr(e)
>

-- 
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/CAO5X8CxOnYpMcTp3zS%2B%2BqgCL2-1tq0PnxU7mB0AXNHKS_SriCA%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Sun, Jan 12, 2020 at 8:18 AM Edward K. Ream  wrote:

>
>
> On Sat, Jan 11, 2020 at 2:11 PM Brian Theado 
> wrote:
>
> > I have doubts about the following entries you are suppressing: assert,
> except, raise.
>
> Imo, they are fine.  Assert signal that something is seriously wrong with
> the tool, not the user input.
>

My suggestion was to allow coverage to report on execution of assert
statements. It sounds to me like you are responding as if I suggested to
test assertion failures. Code coverage reporting can't distinguish between
when the assertion fails and when it doesn't.

I only found 2 instances of assert statements not being covered when I
change .coveragerc to include asserts and re-ran the tests. In both cases
they are else clauses which your current tests don't cover.

if e is not None: assert e.lower() == 'utf-8', repr(e)

-- 
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/CAO5X8CwTzUtx-NcUqq6NOGMFGW6t%2BEb_OEZ%2BNF1vd_U-aqUYGA%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Fri, Jan 10, 2020 at 8:33 AM Edward K. Ream  wrote:

> > I still think full line-by-line coverage analysis will be very valuable.
>>
>> I agree. I have just created #1474
>>  for this.
>>
>
> Many thanks for suggesting this. `pytest --cov` has quickly become one of
> my favorite tools, on a par with pyflakes and pylint.
>

Excellent. I'm glad it is helpful.

pytest is easy to configure, and it's easy to suppress coverage test within
> the code itself. leo-editor/.coveragerc now contains the default settings.
>

I was unaware of that feature. Looks useful.

I have doubts about the following entries you are suppressing: assert,
except, raise.

For all 3, it seems like a case-by-case "pragma: no cover" is better than
wholesale suppression.

Especially assert. In general, an assert will precede other code you will
already want cover with tests, so why suppress the coverage report from the
assert statement itself?

With except and raise there might be some cases in which the code can't be
hit unless there is a bug in your library code. Since you can't anticipate
your bugs, you would want to suppress those from the coverage report. But
in most cases, I expect the exception catching and raising will be for
cases in which the user passes in bad data. It would be valuable to
exercise that code in unit tests to ensure it works the way you expect if a
user encounters it.

So my 2 cents says it would be better to have case-by-case suppression for
the exceptions catching and raising whose purpose is to alert you to bugs
in your own code.

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/CAO5X8CzCwRF2%3DsiiXOGBJ8F_tgGHEnSnY3DXbz2GA9h2KQEBYg%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Thu, Jan 9, 2020 at 5:10 AM Edward K. Ream  wrote:

> On Wed, Jan 8, 2020 at 5:55 AM Brian Theado 
> wrote:
>
> > I often read unit tests in source code projects in the hope of finding
> simple, concrete usage examples. These examples not only serve to test the
> code, but also also documentation on how to use it.
>
> > But from that I don't see what the outputs are. It doesn't show me what
> a TOG object can do and what it is for.
>
> For an overview, see the Theory of Operation in LeoDocs.leo.
>

Thanks, I did read those docs and didn't find what I was looking for. Maybe
after I understand better, I can provide some concrete, constructive
feedback on those docs.


> > Is there some code you can add which make it easy to see how things
> work?
>
> Good question.  The dozen or so tests in the TestFstringify class assert
> that a small example produces the desired result.
>

Yes, those are nice. Concrete inputs and concrete outputs in the test.
Exactly what I was hoping for in a least few of the TOG tests.


> To see the two-way links produced by the TOG class, just call
> dump_tree(tree) at the end of *any* test. For example, in
> TestTOG.test_ClassDef2, replace:
>
> self.make_data(contents)
>
> by:
>
> contents, tokens, tree = self.make_data(contents)
> dump_tree(tree)
>
> The output will be:
>
> Tree...
>
> parent   lines  node   tokens
> ==   =     ==
>  6..7   0.Module:  newline.33(
> 6:0)
>   0.Module1.Expr:
>   1.Expr 1  2.Str: s='ds 1'string.1("""ds
> 1""")
>   0.Module   1..2 3.ClassDef:  newline.2(1
> :11) name.3(class) name.5(TestClass) op.6=:
>   3.ClassDef4.Expr:
>   4.Expr 2..3 5.Str: s='ds 2'  newline.7(2
> :17) string.9("""ds 2""")
>   3.ClassDef 3..4   6.FunctionDef: newline.10(
> 3:15) name.12(def) name.14(long_name) op.23=:
>   6.FunctionDef  47.arguments: op.20==
>   7.arguments4  8.arg: name.16(a)
>   7.arguments4  9.arg: name.19(b)
>   7.arguments4  10.Num: n=2number.21(2
> )
>   6.FunctionDef   11.Expr:
>  11.Expr 4..5   12.Str: s='ds 3'   newline.24(
> 4:27) string.26("""ds 3""")
>   6.FunctionDef   13.Expr:
>  13.Expr14.Call:
>  14.Call 5..6 15.Name: id='print'  newline.27(
> 5:19) name.29(print)
>  14.Call 616.Str: s='done' string.31(
> 'done')
>
>
This looks useful, thanks. I'll take a look.

-- 
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/CAO5X8Cwu%3DvcOx_Oz3YSd%3DeFvqU30um5jTxFN4VCmHBKiRTr%3DKA%40mail.gmail.com.

Re: Using Vitalije's code patterns

[Brian Theado]

On Thu, Jan 9, 2020 at 5:28 AM Edward K. Ream  wrote:

> On Wed, Jan 8, 2020 at 10:49 PM Brian Theado 
> wrote:
>
> *>> Prefer functions to classes/methods*
>
> > The TokenOrderTraverser class looks to me like a good opportunity to
> follow the above principle. AFAICT, the way it is written, that class is
> ONLY useful if it is subclassed.
>
> True.
>

I'm guessing this is a response only to my 2nd sentence and not both
sentences?


>
> > For me, subclassing is usually extra friction and the resulting code is
> less clear.
>
> Without a class, you would have to implement visit as a callback.
>

Isn't the purpose of 'visit' to be able to loop over the nodes? Sounds like
the job of a for loop to me. No callbacks and no classes needed.

Having the traverse functionality reside in a method of TOT forces the user
to subclass. Extracting it into a separate function like
traverse_in_token_order allows the user to choose to use a for loop
instead. The TOT class can still exist. It would call the same
traverse_in_token_order convenience function. If the user want to do the
extra work of subclassing TOT, they still can.

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/CAO5X8CyfcQRWX7yPHWXaSY-tdJ%3DxRhtWH_7qZyJfvm1XcJYMZA%40mail.gmail.com.

Re: Using Vitalije's code patterns

[Brian Theado]

On Tue, Jan 7, 2020 at 7:58 AM Edward K. Ream  wrote:

> While working on leoAst.py, I have come to understand more fully several
> of Vitalije's suggested code patterns:
>
> *Prefer functions to classes/methods*
>

The TokenOrderTraverser class looks to me like a good opportunity to follow
the above principle. AFAICT, the way it is written, that class is ONLY
useful if it is subclassed. For me, subclassing is usually extra friction
and the resulting code is less clear.

If the TokenOrderTraverser.traverse method were written as a function (say
'traverse_in_token_order(tree)') which is exactly the same except in place
of calling self.visit(node), it will 'yield node'. Then if you really think
you still need to have the TokenOrderTraverser class, you could still
implement then the traverse method:

def traverse(self, tree):
for node in traverse_in_token_order(tree):
self.visit(node)


IMO, the fstringify code would be clearer if it were not written as a
subclass of TOT.

With the subclass way, this is the minimum I could imagine to print all the
nodes:

class TokenOrderPrinter(TokenOrderTraverser):
def print(tree):
self.traverse(tree)

def visit(node):
print(str(node))

TokenOrderPrinter().print(tree)


The function/generator way has so much less friction for the developer
using it:

for node in traverse_in_token_order(tree):
print(str(node))


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/CAO5X8CzULeNHG5NnfmtqhiBdNz34LWJg4yJOEBOBR_nDx8_7cA%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

I've been thinking about this more and studying the code and reading some
of your initial documentation.

I often read unit tests in source code projects in the hope of finding
simple, concrete usage examples. These examples not only serve to test the
code, but also also documentation on how to use it.

For being able to see concrete inputs, the test methods of the TestTOG
class do a good job. For example:

def test_attribute(self):
contents = r"""\
open(os.devnull, "w")
"""
self.make_data(contents)


But from that I don't see what the outputs are. It doesn't show me what a
TOG object can do and what it is for. From the "Generator" in the name, I
can guess that somehow there is a generate involved, so I should be able to
look over it or create a list from it. But how is that done. I look at the
make_data method, but that doesn't clear things up for me.

Is there some code you can add which make it easy to see how things work?
Something like this for example:

next(TokenOrderGenerator.fromString(r"""open(os.devnull, "w")""")) == ???

or

list(TokenOrderGenerator.fromString(r"""open(os.devnull, "w")""")) == [???,
???, ???]


I don't know what to put in the question marks above because I still don't
understand what things tog generator instances yield.

The "fromString" is a hypothetical static factory method (
https://stackoverflow.com/questions/929021/what-are-static-factory-methods/929273)
which makes it easy to instantiate the class.

On Tue, Jan 7, 2020 at 1:32 PM Brian Theado  wrote:

>
>
> On Tue, Jan 7, 2020 at 5:01 AM Edward K. Ream  wrote:
>
>> On Sunday, December 29, 2019 at 7:19:03 PM UTC-5, btheado wrote:
>>
>> I was looking at the tests in leoAst.py in the fstringify branch and I
>>> don't find any asserts in the tests themselves.
>>>
>>
>> The tests in the TestTOG are actually extremely strong.  I have just
>> added the following to the docstring for the TestTOG class:
>>
>> QQQ
>> These tests call BaseTest.make_data, which creates the two-way links
>> between tokens and the parse tree.
>>
>> The asserts in tog.sync_tokens suffice to create strong unit tests.
>> QQQ
>>
>
> I'll take your word for it as it isn't obvious to me from a glance at the
> code. I don't have a huge interest in the tokens project so I don't really
> understand where the parse tree is coming from and how it relates to the
> tokens. Maybe if I really want to understand, I can intentionally break the
> code in a few places and see how the failures work.
>

-- 
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/CAO5X8Cw0%2B9d-j5xsuMVJY%3DTSQM0UqJ0jO2BzEdo-k38kP8x5LQ%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Tue, Jan 7, 2020 at 5:01 AM Edward K. Ream  wrote:

> On Sunday, December 29, 2019 at 7:19:03 PM UTC-5, btheado wrote:
>
> I was looking at the tests in leoAst.py in the fstringify branch and I
>> don't find any asserts in the tests themselves.
>>
>
> The tests in the TestTOG are actually extremely strong.  I have just added
> the following to the docstring for the TestTOG class:
>
> QQQ
> These tests call BaseTest.make_data, which creates the two-way links
> between tokens and the parse tree.
>
> The asserts in tog.sync_tokens suffice to create strong unit tests.
> QQQ
>

I'll take your word for it as it isn't obvious to me from a glance at the
code. I don't have a huge interest in the tokens project so I don't really
understand where the parse tree is coming from and how it relates to the
tokens. Maybe if I really want to understand, I can intentionally break the
code in a few places and see how the failures work.

-- 
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/CAO5X8Czko%3DQ7J5F6d-zb0vdTHjohhD84v0e4_RYphqBi63Cvmw%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

On Sun, Dec 29, 2019 at 5:54 PM Edward K. Ream  wrote:

> On Sun, Dec 29, 2019 at 5:29 PM Brian Theado 
> wrote:
>
[...]

> > You might also find the code coverage report useful:
>
> Yes, that's interesting. The TOG classes remember which visitors have
> been visited, so that's probably enough.
>

It still think full line-by-line coverage analysis will be very valuable. I
ran it like this:

pip install pytest-cov
pytest --cov-report html --cov-report term-missing --cov=leo.core.leoAst
leo/core/leoAst.py
firefox htmlcov/leo_core_leoAst_py.html  ;# Or whatever your web browser is


It shows only 52% coverage, but maybe there is a lot more to that file
which you don't want to test?

The TOG class looks to have a higher percentage of the code covered than
that, but there are still plenty of gaps.  Maybe you aren't viewing the
your visitor report or have not yet prioritized adding tests for all the
visitors, but here is a partial list of completely untested methods:

sync_newline
do_AsyncFunctionDef
do_Interactive
do_Expression
do_Constant
do_ExtSlice
do_Set
do_SetComp


Even in the methods which are tested, there are some interesting-looking
branches of code not tested. Here are some examples:

   1. do_Keyword, the if node.arg branch
   2. do_Slice, if step is not None branch
   3. do_Dict, "Zero or more expressions" for loop
   4. do_FunctionDef, if returns is not None branch
   5. the visitor method itself has several untested sections

BTW, I had to change the hard-coded directory path in make_file_data in
order to get all the tests to pass

-- 
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/CAO5X8Cy%3DXRY6A78WDeJ2xwqa5%2BvTE-TiQvgGXXguZiXVaa3v8Q%40mail.gmail.com.

Re: Question about "Import leoGlobals, but do NOT set g."

[Brian Theado]

On Fri, Jan 3, 2020 at 7:21 AM Edward K. Ream  wrote:

> On Thu, Jan 2, 2020 at 12:11 PM Brian Theado 
> wrote:
>
> For runLeo.py, the code looks like this:
>>
>> # Import leoGlobals, but do NOT set g.
>> import leo.core.leoGlobals as leoGlobals
>> # Create g.app.
>> import leo.core.leoApp as leoApp
>> leoGlobals.app = leoApp.LeoApp()
>> # **Now** we can set g.
>> g = leoGlobals
>> assert(g.app)
>>
>>
>> I thought the 'g' and 'leoGlobals' identifiers are local to the runLeo.py
>> file. I don't see how having the name be 'leoGlobals' instead of 'g' for
>> two lines of code could affect anything.
>>
>
> I don't remember the details, but I suspect that they concern the binding
> of g while leoGlobals.py itself is being imported.
>

I was thinking along these lines, but if that is the case, then I have a
big gap in my understanding of how python identifiers and binding works and
I want to close the gap.


> If you really want to know why the code is as it is, create a new branch
> and change the code ;-)
>

Excellent advice.  I just now tried it though and nothing broke. I was able
to run the gui just fine and I was also able run all the unit tests fine. I
made the changes to both runLeo and leoBridge.

-- 
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/CAO5X8Cy%2BNQM9wVTtezR-MWLtbjHDoS%3DUnYPpqvnwTNTn%2BmNTMA%40mail.gmail.com.

Question about "Import leoGlobals, but do NOT set g."

[Brian Theado]

Both of these places in Leo's code:
https://github.com/leo-editor/leo-editor/blob/devel/leo/core/runLeo.py#L24
https://github.com/leo-editor/leo-editor/blob/devel/leo/core/leoBridge.py#L108

has the comment "Import leoGlobals, but do NOT set g."

For runLeo.py, the code looks like this:

# Import leoGlobals, but do NOT set g.
import leo.core.leoGlobals as leoGlobals
# Create g.app.
import leo.core.leoApp as leoApp
leoGlobals.app = leoApp.LeoApp()
# **Now** we can set g.
g = leoGlobals
assert(g.app)


I thought the 'g' and 'leoGlobals' identifiers are local to the runLeo.py
file. I don't see how having the name be 'leoGlobals' instead of 'g' for
two lines of code could affect anything. IOW, how is the above code any
different from:

import leo.core.leoGlobals as g
# Create g.app.
import leo.core.leoApp as leoApp
g.app = leoApp.LeoApp()
assert(g.app)


Is there something about python identifiers I'm missing?

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/CAO5X8CysF4msw%3DgsiNv3pT_N2ZiKr7G%2BB9vYVtO1i1PLsUz5pQ%40mail.gmail.com.

Re: Leo requires tkinter module to be configured in Python environment

[Brian Theado]

Viktor,

On Tue, Dec 31, 2019 at 11:45 AM Viktor Ransmayr 
wrote:

> You were right with your assumption. - I tried it both with Leo 6.1-final
> as well as 6.2-b1-devel - and - it works as you suspected.
>
> In both cases it does throw a type error related to ...\spellCommands.py -
> but - it does open the workbook.leo outline.
>

Looks like you ran into issue
https://github.com/leo-editor/leo-editor/issues/1453. I just posted a
comment there stating that the attempted fix for that issue did not work.


> Thanks a lot for your explanation!
>
> With kind regards,
>
> Viktor
>
> PS: Just for the record - Here's the startup log for Leo 6.2-b1-devel:
>
> Leo Log Window
> Leo 6.2-b1-devel
> Python 3.7.6, PyQt version 5.12.6
> Windows 10 AMD64 (build 10.0.18362) SP0
> current dir: C:/Users/Viktor/pyve/github/Leo-devel
> load dir: C:/users/viktor/pyve/github/leo-devel/devel/leo-editor-devel/leo
> /core
> global config dir: C:/users/viktor/pyve/github/leo-devel/devel/leo-editor-
> devel/leo/config
> home dir: C:/Users/Viktor
> reading settings in C:/users/viktor/pyve/github/leo-devel/devel/leo-editor
> -devel/leo/config/leoSettings.leo
> Do spellpyx.txt file found
> unexpected error creating: None
> Traceback (most recent call last):
>
>   File
> "c:\users\viktor\pyve\github\leo-devel\devel\leo-editor-devel\leo\commands\spellCommands.py"
> , line 62, in create
> f = open(fn, mode='wb')
>
> TypeError: expected str, bytes or os.PathLike object, not NoneType
>
> reading settings in C:/users/viktor/pyve/github/leo-devel/devel/leo-editor
> -devel/leo/doc/CheatSheet.leo
>
>
>
>
> --
> 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/0214f56c-76bf-4c44-a55e-cddb740333ca%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/CAO5X8CwbwvcQKhQ_QaL4P1HPtknqZ8RHEEvbrsmC%2B0E2qTXULg%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

Edward,

On Sun, Dec 29, 2019 at 5:54 PM Edward K. Ream  wrote:
[...]

> > You might need to introduce failed tests in order to experience the
> better assert failure reporting?
>
> Leo's existing unit tests use asserts.  It's no big deal.
>

I was looking at the tests in leoAst.py in the fstringify branch and I
don't find any asserts in the tests themselves. I expected to find
assertions which verify the actual results of the test match some expected
results. Is this just an early version of the tests or do you have some
different approach?

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/CAO5X8CzdA6dUDaNX2A4KM5urteePEpDRQB9WOOonyXoTmu6GJw%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

Edward,

On Sun, Dec 29, 2019 at 2:03 PM Edward K. Ream  wrote:

> On Saturday, December 28, 2019 at 10:44:39 AM UTC-5, btheado wrote:
>
> I've been experimenting lately writing pytest tests for leo. I just
>> published my work at
>> https://github.com/btheado/leo-editor/tree/pytest-experiment.
>>
>
>> You should be able try it out with these commands (untested):
>>
>> git origin add btheado https://github.com/btheado/leo-editor.git
>> git checkout btheado pytest-experiment
>> pip install pytest
>> pytest leo/test/pytest
>>
>>
> The first line didn't work.  I did `git clone
> https://github.com/btheado/leo-editor.git brian`, but I don't see the
> pytest folder in the leo/test folder, which is strange.
>

Sorry about that. Not sure what is wrong with my instructions. Your clone
should work just as well. From the clone be sure you are on the
pytest-experiment branch (git checkout pytest-experiment). Did you already
try that and not find the leo/test/pytest folder? If that doesn't work, I'm
not sure what to say other than you can view the code at github:
https://github.com/btheado/leo-editor/tree/pytest-experiment/leo/test/pytest


> With my present setup,  `pytest leo\core\leoAst.py` executes all the
> present unit tests in leoAst.py:
>
> leo\core\leoAst.py
> ...
>
> == 71 passed in 5.42 seconds
> ==
>
> So I don't understand what difference pytest makes.  What am I missing?
>

According to https://docs.pytest.org/en/latest/unittest.html#unittest,
pytest supports running unittest style tests. That page has a list of
purported benefits of using pytest even for unittest style tests. I haven't
used unittest to write tests, I only know I like the function-based style
which pytest encourages. As it says on the main page (
https://docs.pytest.org/en/latest/index.html): "The pytest framework makes
it easy to write small tests, yet scales to support complex functional
testing for applications and libraries."

You might need to introduce failed tests in order to experience the better
assert failure reporting?

You might also find the code coverage report useful:

pip install pytest-cov
pytest --cov-report html --cov-report term-missing --cov=leo.core.leoAst
leo/core/leoAst.py
firefox htmlcov/leo_core_leoAst_py.html



> Btw, giving a directory does *not* work (pytest 3.6.7).  For example,
> pytest leo\core finds no tests.
>

https://docs.pytest.org/en/latest/goodpractices.html#test-discovery - the
default test discovery for pytest will only find tests within test_*.py or
*_test.py files

3.6 is almost a year and a half old, I think. I only started using pytest
version 5.2+, so I'm not very familiar with old versions. Might be useful
for you to upgrade.

-- 
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/CAO5X8CwhiAk3LYmy7jzg%3DRsQ_3CWmLJ-6Os0rxYgkh%2B%3DzJxnYw%40mail.gmail.com.

Re: #1467: Use traditional unit test (almost?) everywhere

[Brian Theado]

I've been experimenting lately writing pytest tests for leo. I just
published my work at
https://github.com/btheado/leo-editor/tree/pytest-experiment.

You should be able try it out with these commands (untested):

git origin add btheado https://github.com/btheado/leo-editor.git
git checkout btheado pytest-experiment
pip install pytest
pytest leo/test/pytest


The tests I wrote are in leo/test/pytest.leo

The first set of tests I wrote are for testing the leoNode.py file. I was
interested in seeing what it was like to try to get full code coverage by
the tests. There is a project called coverage.py (
https://coverage.readthedocs.io) which can produce nice reports about which
lines of code have been executed and which have not. I tried using this
coverage.py against leo's current unit tests. Somehow coverage.py was not
able to properly mark all the executed code. I suspect something in Leo's
unit tests caused coverage.py to lose track but I'm not sure. I planned on
doing binary search through the unit tests (enable/disable) until I found
which ones caused coverage to lose its way. I never got around to doing
that and instead used the pytest coverage.py plugin on some unit tests I
wrote.

My leo/test/pytest/leoNodes_test.py file contains 24 tests. I picked some
methods of the Position class in leoNodes.py and strove to get full
coverage on them. With 24 tests, I did fully cover them, but it is only a
small percentage of the whole file. You can see the coverage achieved by
running these commands:

pip install pytest-cov
pytest --cov-report html --cov-report term-missing --cov=leo.core.leoNodes
leo/test/pytest/leoNodes_test.py
firefox htmlcov/leo_core_leoNodes_py.html  ;# Or whatever your web browser
is


The resulting web page highlights all the lines of code which haven't been
executed in red. From the tests I wrote, you should see 100% coverage for
several of the Position methods including the comparison
operators, convertTreeToString, moreHead,
moreBody, children, following_siblings, nearest_roots,
and nearest_unique_roots.

In the process of writing those tests, I found what I think is a bug and I
discovered the very nice xfail (
https://docs.pytest.org/en/latest/skipping.html#xfail) feature of pytest.
With it you can mark test that you expect to fail with the xfail decorator.
This will suppress all the verbose information pytest gives when there is a
failure (stack trace, etc), Normally, this verbose information is helpful
in tracking down the reason for failures. But if the bug is one which can't
or won't be fixed right away, all the extra information can get in the way.
So the xfail marker will suppress all the failure details unless you run
using the --runxfail command line option. That way you can keep your pytest
runs clean, but then easily access the failure details when you are ready
to fix the bug.

To see the details of the expected failures I've identified as bugs (2 of
them so far), run it like this:

pytest leo/test/pytest --runxfail


I'm a big fan of writing tests which fail before a bug is fixed and pass
after a bug is fixed. The xfail feature is very helpful in this regard.

Pytest also has the feature of fixtures (
https://docs.pytest.org/en/latest/fixture.html) which I've made use of. It
allows all tests to be written as simple functions. No classes needed.
Anything which normally would be done in a setup method can be implemented
as a fixture instead. It seems there are some tradeoffs here, but overall I
like it a lot.

Fixtures can be defined in any test file, but if they are common to
multiple test files, they can be defined in a file named conftest.py. This
makes the fixtures available to all the files in the directory. I've
defined my fixtures there.

My fixtures include a bridge fixture which can be used to access the leo
bridge. I also have fixtures for several example outlines. I didn't like
that the fixtures ended up "distant" from the tests themselves, so I came
up with a naming convention for the example outlines which allows you to
know the exact structure and contents of the outline just by looking at the
name of the outline. I tried to explain this naming convention in
conftest.py, but I'm not sure if it will be clear to anyone other than
myself.

Using pytest provides a lot of benefits:

   - Information provided about failures is excellent
   - marking expected failures with xfail is very useful for documenting
   bugs before they are fixed
   - fixtures allow all tests to be written as simple functions
   - coverage plugin allows code coverage to be measured
   - there are many, many other plugins

I'm not suggesting leo switch to using pytest. With this work I've shared,
I hope it is easy for those familiar with leo unit tests to be able to
evaluate the nice features of pytest and decide whether it is worth further
consideration.

On Sat, Dec 28, 2019 at 8:40 AM Edward K. Ream  wrote:

>
> On Saturday, December 28, 2019 at 6:07:03 AM UTC-5, vitalije wrote:
>
> For a 

Re: How to install console leo w/o installing pyqt?

[Brian Theado]

Just don't install pyqt at all.

I was playing with the web app version of flexx a while back and I think I
only installed these pip packages:

pip install docutils nbformat pylint pypandoc sphinx semantic_version flexx


and then ran leo from the git checkout with --gui=browser.

You should be able to replace flexx above with whatever pip package
provides the curses functionality.


On Sun, Dec 22, 2019 at 11:47 PM gar  wrote:

> I have a very ancient notebook, it is still 32bits. surprisingly recent
> lubuntus run fine there.
> I use it time after time but! I cannot use it with .leo files cause it is
> absolutely impossible to install Leo on 32bit systems since pyqt is
> required and pyqt for itself supports only 64bit linuxes.
> I'd love to have a chance to use console gui, but cannot imagine how to do
> it.
> Clone from git, install all deps manually, ignore failed pyqt? Is it
> possible to ask pip install all ignoring failed packages?
>
> --
> 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/7376413a-8242-49a6-88ce-33435be99137%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/CAO5X8CwV%3DpEgk0C%3DVQVoGqPqD2tPv0Hap1EExUM7UfnuDA-%3DUQ%40mail.gmail.com.

Re: Progress report re #1451: unsaved files

[Brian Theado]

Edward,

On Sun, Dec 15, 2019 at 5:42 PM Edward K. Ream  wrote:

> On Sun, Dec 15, 2019 at 7:59 AM Brian Theado 
> wrote:
>
[...]

> That behavior doesn't seem to be the most user friendly. Better that than
>> having the bug where changes are lost, but I wonder if there is a way to
>> have both without it being too complicated?
>>
>
> This is actually a completely different issue :-)  #1451 involves making
> sure that all external files are written, which devolves into making sure
> that all @ nodes are marked dirty when they need to be.
>

It is a different issue, but one being created as "collateral damage" by
the dirty changes you are making for #1451. Or am I misunderstanding? I
mean the scenario I described where the user gets unnecessarily prompted
about saving changes it not present prior to #1451 changes.


> The behavior you mention involves making sure that the user is given the
> opportunity to save external files (and the outline itself) when they try
> to close the outline.  Leo's behavior is standard in this regard, with the
> proviso that change may "cancel" so that no change is actually made.  It
> would be possible to do a trial write to see if there were any change, but
> that's a nit, and it would substantially complicate the code.  Imo, it's
> not worth doing.
>

I agree having code which does a trial write is not worthwhile. However,
having code which did perfect dirty bookkeeping could be worthwhile if it
were easy enough to do and be sure enough it won't cause any data loss.


>
> Just thinking out loud, but maybe it would work to have a dirty counters
>> for the nodes. After a save, all the dirty counters are reset to zero. Undo
>> operations decrement the dirty counter for affected nodes and redo
>> operations increment the counter. Any time a given node's counter is at
>> zero, the dirty bit is cleared and any time the counter is non-zero, the
>> bit is lit.
>>
>
> There have been proposals for per-node undo, and this is similar.  After
> congratulating myself on eliminating evil undo-related state, I am in no
> mood to add any new caching.  The total advantage of such a scheme, in the
> entire projected history of the universe, does not begin to compare with
> the pain that any bug in such a scheme would cause.
>

The way I describe it implies two separate pieces of data (dirty counter
and dirty bit) and I think that's what you mean when you say "new caching"?
I don't think perfect bookkeeping of dirty bits necessarily requires the
use of caching, but I can appreciate that implementing such perfect
bookkeeping might be quite difficult in a complicated code base and not
worth the trouble.

I just wanted to raise the issue to make sure the trade offs were clear.
The user is getting a good bargain: losing a little by getting
unnecessarily prompted for saving files which are unchanged, but gaining a
lot by making sure all external files are written.

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/CAO5X8Czs_X%2Bo8-xA477_%2BoV-WX6pkjQuCWUo4QTMWu_nTcYhTw%40mail.gmail.com.

Re: Progress report re #1451: unsaved files

[Brian Theado]

If I'm understanding correctly, with your planned changes if a user opens a
leo file and makes a few changes and then undoes all the changes and tries
to close the file, then the user will be prompted about saving changes even
though the outline matches everything on disk. Is that correct?

That behavior doesn't seem to be the most user friendly. Better that than
having the bug where changes are lost, but I wonder if there is a way to
have both without it being too complicated?

Just thinking out loud, but maybe it would work to have a dirty counters
for the nodes. After a save, all the dirty counters are reset to zero. Undo
operations decrement the dirty counter for affected nodes and redo
operations increment the counter. Any time a given node's counter is at
zero, the dirty bit is cleared and any time the counter is non-zero, the
bit is lit.

On Sat, Dec 14, 2019 at 11:31 AM Edward K. Ream  wrote:

> The complexity of the undo code has collapsed. This is a most welcome
> milestone:
>
> - All the dirtyVnodeList kwargs and associated logic are gone.  This is
> big.
>
> The undo/redo code now just calls p.setDirty one or more times. This works
> because p.setDirty now calls v.setAllAncestorAtFileNodesDirty. This is
> feasible because Vitalije's code is super fast, and because it uses vnodes,
> not positions.
>
> When moving node.p, the pattern is:
>
> p.setDirty()
> << do the move >>
> p.setDirty()
>
> The point is that moving a node may change its parents, so both calls to
> p.setDirty are necessary.
>
> This is surely the simplest thing that could possibly work.  However, I am
> tempted to have the low-level VNode methods call
> v.setAllAncestorAtFileNodesDirty "automagically".  This is feasible now
> that marking nodes dirty happens in the vnode world, not the position
> world.  However, I probably *won't* go that far: the low-level vnode
> methods probably don't have enough context to do the right thing reliably.
>
> - v.setAllAncestorAtFileNodesDirty no longer returns a dirtyVnodeList, so
> I was able to collapse the complexity of that method as well.
>
> I have thoroughly reviewed all aspects of the undo code.  However, more
> simplifications may be possible, and a few arcane questions remain.  It's
> possible that those questions represent edge cases that could cause bugs.
> I expect to work on this issue for a day or two more.
>
> 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/2874489c-defe-4bdf-90a9-b2c6639858ef%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/CAO5X8CxzOWVQ2Tq5C4T_-ex-7G%2B5Oxj0qU2pJOp9aLzoMoo0UA%40mail.gmail.com.

Re: book authoring: formatting, auto-save, auto-commit to git

[Brian Theado]

See also this thread:
https://groups.google.com/d/msg/leo-editor/1VOYPUJrNEM/ItZwstC0AwAJ. It
might be helpful related to git autocommit.

On Fri, Dec 6, 2019 at 12:36 PM Terrence-Monroe: Brannon <
thequietcen...@gmail.com> wrote:

> I found a good answer to git auto-committing:
> https://stackoverflow.com/questions/420143/making-git-auto-commit
>
> On Friday, December 6, 2019 at 9:07:34 AM UTC-8, Terrence-Monroe: Brannon
> wrote:
>>
>> Regarding book authoring:
>>
>> What formatting (rst, asciidoc) works well to make a book with Leo?
>>
>> If I want my work to be automatically auto-saved how can this be
>> achieved? Google docs automatically saves as I type (so does Evernote).
>>
>> If I want my work to be auto-committed to a git repo, how can this be
>> achieved?
>>
>> --
> 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/844f885d-0f88-4b05-b666-d02367529dc8%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/CAO5X8CxgpDk0p8VH7G-r61v%2BuU9H96tbK24_4wbfq-JNRP-4wg%40mail.gmail.com.

Re: Enhancing color scheme

[Brian Theado]

gar,

Previously, you wrote this:

> I find color schemes supplied with the leo's distr poor for some
languages (for example,
>javascript still knows nothing about es6/es7, and markdown ignores back
quotes) and want to
> enhance them (and even introduce some more).

> How should I use changed version? I should edit files in the git repo and
then make a pull request?

It sounds like you are making improvements which would benefit everyone.
IMO, for those cases it would make sense to edit the files in the git repo
and make a pull request.

Brian


On Fri, Dec 6, 2019 at 2:56 AM gar  wrote:

> Fantastic, thanks a lot! I am very poor pythonista and learnt something
> new from your code.
> It creates a new dialect from nothing, and that's cool.
> But... how can I patch existing dialect? Acquire it, re-define methods of
> interest and hope that it would work?
>
> четверг, 5 декабря 2019 г., 21:53:38 UTC+3 пользователь btheado написал:
>>
>> This thread may interest you: "Defining colorizer modes in @script"
>> https://groups.google.com/d/msg/leo-editor/X9tjxbOq6es/lxyaIooWQzsJ.
>>
>> I never followed through on avoiding the need for the monkey patch. I
>> don't use this code anymore and when I tested it didn't work. I made a
>> small change (highlighted in bold below) and now it is working again. To
>> test it yourself, "Paste as node" the following xml. Then highlight "sol
>> colorizing" node and hit ctrl-b to execute it. Then select "colorizing
>> test" node and see the highlighted date string
>>
> --
> 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/b047dd9a-5d9e-4ee0-87e6-65a198ddefc6%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/CAO5X8Cze2ma3fj2vB%3D6AiQpP-%2Ba-P-uYO8dQDQ%3DefBvQg%2Bk75g%40mail.gmail.com.

Re: Enhancing color scheme

[Brian Theado]

Sorry, I meant ctrl-shift-V

On Thu, Dec 5, 2019 at 3:00 PM Brian Theado  wrote:

> Copy the xml text to your clipboard. Open a leo outline and hit
> ctrl-shift-C. Or right click on a node and select "Paste Node"
>
> On Thu, Dec 5, 2019 at 2:53 PM gar  wrote:
>
>> Thanks!
>> But how can I paste raw xml as a node? Couldnt even imagine that this
>> were possible
>>
>> четверг, 5 декабря 2019 г., 21:53:38 UTC+3 пользователь btheado написал:
>>>
>>> This thread may interest you: "Defining colorizer modes in @script"
>>> https://groups.google.com/d/msg/leo-editor/X9tjxbOq6es/lxyaIooWQzsJ.
>>>
>> --
>> 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/498f9cde-a23e-461b-8215-ed41c5932842%40googlegroups.com
>> <https://groups.google.com/d/msgid/leo-editor/498f9cde-a23e-461b-8215-ed41c5932842%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAO5X8CwH58Z%3Duq9y03bLAQrfKvP8DaDCJO-ywwvV_nNJfd6i7w%40mail.gmail.com.

Re: Enhancing color scheme

[Brian Theado]

Copy the xml text to your clipboard. Open a leo outline and hit
ctrl-shift-C. Or right click on a node and select "Paste Node"

On Thu, Dec 5, 2019 at 2:53 PM gar  wrote:

> Thanks!
> But how can I paste raw xml as a node? Couldnt even imagine that this were
> possible
>
> четверг, 5 декабря 2019 г., 21:53:38 UTC+3 пользователь btheado написал:
>>
>> This thread may interest you: "Defining colorizer modes in @script"
>> https://groups.google.com/d/msg/leo-editor/X9tjxbOq6es/lxyaIooWQzsJ.
>>
> --
> 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/498f9cde-a23e-461b-8215-ed41c5932842%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/CAO5X8CzAYJVcOMe47Y-%3DYRTPFqTcnRmEGSVOcT_muXFoMZxy0Q%40mail.gmail.com.

Re: Enhancing color scheme

[Brian Theado]

This thread may interest you: "Defining colorizer modes in @script"
https://groups.google.com/d/msg/leo-editor/X9tjxbOq6es/lxyaIooWQzsJ.

I never followed through on avoiding the need for the monkey patch. I don't
use this code anymore and when I tested it didn't work. I made a small
change (highlighted in bold below) and now it is working again. To test it
yourself, "Paste as node" the following xml. Then highlight "sol
colorizing" node and hit ctrl-b to execute it. Then select "colorizing
test" node and see the highlighted date string.



http://leoeditor.com/namespaces/leo-python-editor/1.1;
>


colorizing sample
sol colorizing
class sol
timestamp colorizer rules

load rule

colorizing test



@language python
@others

# Monkey-patch this method to also recognize the
# 'sol' mode as I didn't figure out how to fix this
# in general
def isValidLanguage (self,language):
fn = g.os_path_join(g.app.loadDir,'..','modes','%s.py' % (language))
return g.os_path_exists(fn) or language == 'sol'

from types import MethodType
c.frame.body.colorizer.isValidLanguage = \
MethodType(isValidLanguage, c.frame.body.colorizer)

class sol:
@others
@language python
# Leo colorizer control file for sol mode.
# This file is in the public domain.

# This mode colorizes timestamp strings like
# '2011/12/04 20:31:16 -' which appear at the
# start of a line

properties = { }

# Attributes dict for solt_main ruleset.
sol_main_attributes_dict = {
"default": "null",
"digit_re": "",
"escape": "",
"highlight_digits": "false",
"ignore_case": "false",
"no_word_sep": "",
}

# Dictionary of attributes dictionaries for sol mode.
attributesDictDict = {
"sol_main": sol_main_attributes_dict,
}

# Keywords dict for sol_main ruleset.
sol_main_keywords_dict = {}

# Dictionary of keywords dictionaries for sol mode.
keywordsDictDict = {
"sol_main": sol_main_keywords_dict,
}

# Rules for sol_main ruleset.
import leo.core.leoGlobals as g

# Rule for the date/timestamp coloring
def sol_rule0(colorer, s, i):
#re = r"\d{8} \d\d:\d\d:\d\d -"
re = r"\d\d\d\d/?\d\d/?\d\d \d\d:\d\d:\d\d -"
m = colorer.match_seq_regexp(s, i, kind="keyword2", regexp=re,
at_line_start=True, at_whitespace_end=False,
at_word_start=False, delegate="")
return m

# Rule for **bold**
def sol_bold(colorer, s, i):
return colorer.match_seq_regexp(s, i, kind="keyword3",
regexp="\\*\\*[^*]+\\*\\*",
at_line_start=False, at_whitespace_end=False, at_word_start=True,
delegate="")

# Rule for *italics*
def sol_italics(colorer, s, i):
return colorer.match_seq_regexp(s, i, kind="keyword4",
regexp="\\*[^\\s*][^*]*\\*",
at_line_start=False, at_whitespace_end=False, at_word_start=True,
delegate="")


# Rules dict for sol_main ruleset. All of the possible first
# matching characters for each rule must have a mapping enumerated
# here. The 'sol_rule0' for example has \d at the front of the
# regexp and so any numeral can match
rulesDict1 = {
"0": [sol_rule0,],
"1": [sol_rule0,],
"2": [sol_rule0,],
"3": [sol_rule0,],
"4": [sol_rule0,],
"5": [sol_rule0,],
"6": [sol_rule0,],
"7": [sol_rule0,],
"8": [sol_rule0,],
"9": [sol_rule0,],
 "*": [sol_bold, sol_italics],
}

# x.rulesDictDict for sol mode.
rulesDictDict = {
"sol_main": rulesDict1,
}

# Import dict for sol mode.
importDict = {}

c.frame.body.colorizer.highlighter.
*colorizer*.init_mode_from_module('sol', sol)
@language sol
2013/11/27 14:05:29 - The date string should be highlighted



On Thu, Dec 5, 2019 at 4:51 AM gar  wrote:

> What I've discovered.
>
> There are 3 coloring engines are in leo:
>   * *jedit* (default and fallback)
>   * *pygments* (@bool use-pygments)
>   * *scintilla* (@bool qt-use-scintilla)
>
> jedit engine can be customized via changing the parts of leo distr (so you
> cannot keep it around w/o polluting leo's sources).
> pygments has disgusting coloring for anything different from python.
> scintilla is critically outdated and cannot be used at all.
>
> So despite the choice availble - there's actually no choice. All end user
> is suitable for is jedit colorizer.
> So I am going to adopt it for my needs. And maybe later I'll get an idea
> how to avoid polluting leo's git.
>
> A hope left that pygments can be in any way configured (installing
> pygments-lexer-babylon didnt help). I'll be investigating further more.
>
> --
> 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/1560bb5e-6e66-465f-9593-10de1266ec33%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this 

Re: Bob H: would distinct Leo IDs help with #1348?

[Brian Theado]

On Fri, Nov 8, 2019 at 8:35 AM vitalije  wrote:

>
>> 1) Eliminate the generation of a GNX before reading a file.
>>>
>>
>> Hmm.  I wasn't aware that Leo did that.  Why does this cause problems?
>>
>> Since the hidden root node always has GNX hidden-root-vnode-gnx, the
>>> motivation for this GNX generation is very mysterious to me.
>>>
>>
>> Me too :-)
>>
>>
> I believe that Leo creates some vnodes during the startup and  therefore
> generates gnx. For example when scripting plugin creates buttons and
> commands it creates and stores v instances.
>
> Perhaps the solution would be to clear gnxDict before reading a new file.
>

The stack trace I included in my comment (
https://github.com/leo-editor/leo-editor/issues/1348#issuecomment-542014635)
shows where I saw the gnx being generated before reading the file.
In this method, I guess:

leo/core/leoFrame.py(706)createFirstTreeNode()

-- 
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/CAO5X8Cyfg%3DqFM0ZsGu%3D8MoX78EyJbtUKBVxOthqmWsRSHbMXWw%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

SegundoBob,

> You give a correct implementation of vnode2allPositions().
[...]
> The implementation of vnode2allPositions() in leoCommand.py is seriously
flawed
[...]
> But vnode2allPositions() is not used by Leo-Editor core

But vnode2allPositions is used in the leo-editor by the method
c.cloneFindParents. The vnode2allPositions method has this in its doc
string:

"Not really all, just all for each of v's distinct immediate parents."


I'm guessing it does exactly what Edward wants it to because he uses the
clone-find-x commands all the time. The clone-find-all-parents command
helps you quickly see the context of other occurences of the clone. But
sometimes the volume of other clones is very high due to distant
ancestors themselves having clone instances. Seeing so many repeated
instances of similar tree structure often becomes too much noise.

 So probably your quibble with vnode2allPositions is that it doesn't do
what you expect it to do based on the name?

For my initial 'show-clones' command (now called 'show-clone-parents') I
wanted the same "reduced noise" approach as clone-find-all-parents and so I
re-used the vnode2allPositions method. Then based on your feedback, I wrote
the show-clone-ancestors which shows all the paths to the clone. Two
different use cases and I thought the latter would fit your use case. Does
it?

> Here is a function that guarantees positions Y and Z display as different
UNL's
> by appending/prepending the child index for Y or Z (child index in
brackets) to
> the headline of X
[...]

Have you seen the with_index and with_count parameters for get_UNL?

def get_UNL(self, with_file=True, with_proto=False, with_index=True,
with_count=False):
"""
with_file=True - include path to Leo file
with_proto=False - include 'file://'
with_index - include ',x' at end where x is child index in parent
with_count - include ',x,y' at end where y zero based count of same
headlines
"""


I didn't take a close look at your code, but is it any different than just
using those options? I didn't include those options in my
show-clone-ancestors, but that is easy to change. I figured the important
part is that if you click on the same-looking links, it will still take you
to the distinct instances of that position

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/CAO5X8Cz1WCD_jc5AHHL7un5ZSurW%2BnUEhjSyMbbDDv8vPuk%2BoQ%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

Edward,

On Thu, Oct 10, 2019 at 12:36 PM Edward K. Ream  wrote:
[...]

> Done at 5e0117d, if I understand you correctly.
>

Thanks!


> I confess that I find both commands confusing, but I'll leave them in.
>

Thanks for the feedback. Do you mean you find the output confusing or how
to use it confusing or confusing why it would be useful?

-- 
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/CAO5X8CzN5WxX%3D9zaSJjQnog-HLdJep4erAi7BsU-z39UxgF23Q%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

I've been thinking about this a lot and I've come to the conclusion that
there should be a separate command that will display all the clone
positions of a given node. Maybe the original could be renamed from
'show-clones' to 'show-clone-parents' and this one could be called
'show-clone-ancestors'

g.es(f"Ancestors of '{p.h}':")
for clone in c.all_positions():
if clone.v == p.v:
unl = clone.get_UNL(with_file=False, with_index=False)
runl = " <- ".join(unl.split("-->")[::-1][1:]) # reverse and drop
first
g.es("  ", newline = False)
g.es_clickable_link(c, clone, 1, runl + "\n")

SegundoBob, this one should work better for your clone structure, though in
general there will be more output from this one than the other one.

On Tue, Oct 8, 2019 at 8:56 AM Brian Theado  wrote:

> In my previous email I was pointing the finger at g.handleUnl doing
> something wrong for SegundoBob's use case. However, I played with that a
> little bit and it seems to handle links to clones with the same parent just
> fine. Now I'm suspecting c.vnode2allPositions is not appropriate for the
> use case.
>
> Try pasting these nodes and use ctrl-b on either of the 'child' clones.
> Then change which line is commented out and use ctrl-b again. In both cases
> the same position is selected. IOW, it looks to me like even though
> c.vnode2allPositions is returning two positions, they both point to the
> same position in the outline. The purpose of vnode2allPositions must be
> different than I expect.
>
> 
> 
> http://leoeditor.com/namespaces/leo-python-editor/1.1;
> >
> 
> 
> test
> child
> 
> 
> 
> 
> @language python
> # Try ctrl-b with each of these lines and
> it will select the same position
> c.selectPosition(c.vnode2allPositions(p.v)[0])
> #c.selectPosition(c.vnode2allPositions(p.v)[1])
> 
> 
> 
>
> On Tue, Oct 8, 2019 at 3:59 AM Edward K. Ream  wrote:
>
>> On Mon, Oct 7, 2019 at 5:49 PM Segundo Bob  wrote:
>>
>> Brian is right.  Edward, I think your fix does not fix the problem.
>>>
>>
>> Please let me know what code you want, and i'll put it in.  Better yet,
>> you could do it yourself.
>>
>> 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/CAMF8tS0DCt4GyhBQ4EG-Ujoj3EuXDuHuorWHYDwsztQnTHRcSw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS0DCt4GyhBQ4EG-Ujoj3EuXDuHuorWHYDwsztQnTHRcSw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAO5X8CwLv%2BAHeKEHQe47Tga5P23dbYb4y87-32%2BZyq1Pf-k_bQ%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

In my previous email I was pointing the finger at g.handleUnl doing
something wrong for SegundoBob's use case. However, I played with that a
little bit and it seems to handle links to clones with the same parent just
fine. Now I'm suspecting c.vnode2allPositions is not appropriate for the
use case.

Try pasting these nodes and use ctrl-b on either of the 'child' clones.
Then change which line is commented out and use ctrl-b again. In both cases
the same position is selected. IOW, it looks to me like even though
c.vnode2allPositions is returning two positions, they both point to the
same position in the outline. The purpose of vnode2allPositions must be
different than I expect.



http://leoeditor.com/namespaces/leo-python-editor/1.1;
>


test
child




@language python
# Try ctrl-b with each of these lines and
it will select the same position
c.selectPosition(c.vnode2allPositions(p.v)[0])
#c.selectPosition(c.vnode2allPositions(p.v)[1])




On Tue, Oct 8, 2019 at 3:59 AM Edward K. Ream  wrote:

> On Mon, Oct 7, 2019 at 5:49 PM Segundo Bob  wrote:
>
> Brian is right.  Edward, I think your fix does not fix the problem.
>>
>
> Please let me know what code you want, and i'll put it in.  Better yet,
> you could do it yourself.
>
> 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/CAMF8tS0DCt4GyhBQ4EG-Ujoj3EuXDuHuorWHYDwsztQnTHRcSw%40mail.gmail.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/CAO5X8CwTJ9LwDip591ou4Ga9CTzaAH5B7b_zfoYe3ceR5r9EEg%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

Thanks, Edward for putting this code into the core as a command.

You interpreted SegundoBob's request differently, than I did. I was
thinking he didn't mind that the duplicates are there (and maybe prefers
it?), just that he wanted the displayed links go to the separate instances
of the clones.

SegundoBob, could you clarify?

On Mon, Oct 7, 2019 at 4:58 PM Edward K. Ream  wrote:

>
>
> On Monday, October 7, 2019 at 3:42:17 PM UTC-5, btheado wrote:
>>
>>
>> The short answer is that this is standard, core Leo code I'm calling. The
>> long answer is that it will take some investigation.
>>
>
> Here is the fix, at rev cc6c47b in devel:
>
> @g.command('show-clones')
> def show_clones(event=None):
> """Display links to all parent nodes of the node c.p."""
> c = event.get('c')
> if not c:
> return
> seen = []
> for clone in c.vnode2allPositions(c.p.v):
> parent = clone.parent()
> if parent and parent not in seen:
> seen.append(parent)
> g.es_clickable_link(c, clone, 1, f"{parent.h} -> {clone.h}\n")
>
> Note that the more pythonic: `for clone in
> list(set(c.vnode2allPositions(c.p.v)))` fails because positions are (on
> purpose) not hashable.
>
> 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/5b3979ca-dc8a-482b-9698-691a304d7379%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/CAO5X8CztAPVPMwfGXmsYNvGRQmC-agnrxYynpgpZPAunznrgZg%40mail.gmail.com.

Re: @button for displaying all parents of a clone to log pane

[Brian Theado]

SegundoBob,

I don't ever have clones with the same parent in my workflow and I didn't
think to test that case. It looks like the g.es_clickable_link method is
making use of UNL rather than positions. It looks to me like the leo getUNL
functionality handles multiple clones with the same parent.  Maybe the
g.handleUnl method (which is the callback when a UNL link is clicked) is
doing something wrong.

The short answer is that this is standard, core Leo code I'm calling. The
long answer is that it will take some investigation.

Brian

On Mon, Oct 7, 2019 at 2:05 PM SegundoBob  wrote:

> btheado,
>
> Thanks, but your code doesn't work if several positions have the same
> parent.  In this case, multiple links for the positions are displayed, but
> they all go to only one of the positions.  I did not figure out what
> determines which of the positions wins.
>
> SegundoBob
>
> --
> 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/daac2df5-8483-4952-9145-78a76d3eaffa%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/CAO5X8CwZLcZhGzyYnxczJMLczQ%3DQzMAiH0pw1dZx1%2Bwrxs6hvQ%40mail.gmail.com.

@button for displaying all parents of a clone to log pane

[Brian Theado]

I'm aware of the clone-find-all-parents command, but usually I want to
display the other parents of a given clone in order to find one of them in
particular. I don't want the new nodes which clone-find-all-parents create,
because I don't want the extra work later of deleting these extra nodes. I
want something more transient.

I'm also aware of the transient nature of the goto-clone command.  It moves
the position selection to the next cloned instance of the current position.
However, searching through the clones only one-at-a-time feels
uncomfortable and slow to me.

I wanted to be able to see all the clones together at once like
clone-find-all-parents and at the same time have nothing leftover to
cleanup like the goto-clone command.

My answer is this small script button which will display links to all the
clones of the current selected position. The headline of the parent and the
clone is displayed:

@button show clones
for clone in c.vnode2allPositions(p.v):
parent = clone.parent()
if parent:
g.es_clickable_link(c, clone, 1, f"{parent.h }->{clone.h}\n")


Thanks to the c.vnode2allPositions and g.es_clickable_link methods, the
code is easy!

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/CAO5X8Cz5CPVQug%3DXMumubg4kw5SB2K6Zsos-O4TMGLtThRUZ0w%40mail.gmail.com.

Re: New plugin history_tracer

[Brian Theado]

Did you actually make a change to your outline? Body edits don't count.
Iirc Vitalije's code doesn't send anything unless a command is executed.

On Thu, Oct 3, 2019 at 3:35 PM Edward K. Ream  wrote:

>
>
> On Thu, Oct 3, 2019 at 10:22 AM vitalije  wrote:
>
>> Try to write leo-ver-server-files.txt using unix new lines. Does
>> leo-ver-serv.exe produces any output in console?
>>
>
> No output in console.  Browser view unchanged.
>
> 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/CAMF8tS3KbhoGxYUBQRr%2BD2vaQRBjAN81DeekMpR%3D0X-AxrNLwQ%40mail.gmail.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/CAO5X8CzjXJaUA%2BBDFs22D2OQvRFh4LsMRZivg4-CFgDp8GJNYQ%40mail.gmail.com.

Re: Pytest command

[Brian Theado]

Vitalije,

I was looking at the execute-pytest code and it looked to me like only the
assertion rewrite functionality from pytest is being used. I would guess
none of the hooks or fixtures and maybe most plugins will work.

I don't much trust my code reading so I figured I'd better test it, but I
only got a stack trace when trying with your example:

Traceback (most recent call last):

  File "/home/btheado/src/leo-editor/leo/core/leoGlobals.py", line
293, in new_cmd_wrapper
func(self, event=event)

  File "/home/btheado/src/leo-editor/leo/core/leoCommands.py", line
729, in execute_pytest
self.execute_single_pytest(p)

  File "/home/btheado/src/leo-editor/leo/core/leoCommands.py", line
761, in execute_single_pytest
rewrite_asserts(tree, script, config=cfg)

  File 
"/home/btheado/src/pyqt-3.7-venv/lib/python3.7/site-packages/_pytest/assertion/rewrite.py",
line 327, in rewrite_asserts
AssertionRewriter(module_path, config, source).run(mod)

  File 
"/home/btheado/src/pyqt-3.7-venv/lib/python3.7/site-packages/_pytest/assertion/rewrite.py",
line 572, in __init__
"enable_assertion_pass_hook"

  File 
"/home/btheado/src/pyqt-3.7-venv/lib/python3.7/site-packages/_pytest/config/__init__.py",
line 976, in getini
self._inicache[name] = val = self._getini(name)

  File 
"/home/btheado/src/pyqt-3.7-venv/lib/python3.7/site-packages/_pytest/config/__init__.py",
line 987, in _getini
value = self.inicfg[name]

AttributeError: 'Config' object has no attribute 'inicfg'

python 3.7.3 and pytest 5.2.0

Do you have any ideas?

On Thu, Sep 26, 2019 at 6:31 AM vitalije  wrote:

> Hm, looking in the output it seems that the name of the test node, and
> failed test function in the output are missed. Revision 064e218
>  fixes this. Now the
> output is like:
>
> ---example/test_a failed-
> assert 4 == 4.1
>  +  where 4 = inc(3)
> ---example/test_b failed-
> assert 18.297 == 18
>  +  where 18.297 = times_3(6.1)
>  +where 6.1 = add_2(4.1)
>  +  where 4.1 = inc(3.1)
>  +  and   18 = times_3(6)
>  +where 6 = inc(5)
> failed:2 tests
>
> 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/b7880eb4-9c2f-4d37-932d-d1f0d72fcfe3%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/CAO5X8Cwq6XSp%2B3gRnTiWzcSyVMSYxbYgeWV43togHiB_7x4eGA%40mail.gmail.com.

Re: leo from devel fail to start on windows

[Brian Theado]

Try looking in your %HOME%/.leo/db directory (or whatever it is on
windows). See if there is a file with scripts.leo in its name. If so, then
move the db directory to db.bak and try starting leo again. I encountered a
similar issue the other day and I didn't realize it might be due to new leo
code.

I'm not clear on the nature of the files in the db directory. Maybe someone
else can explain.

On Tue, Oct 1, 2019 at 12:18 AM gar  wrote:

> python launchLeo.py --no-dock
>
> --global-docks: False
>
> duplicate, (not conflicting) key bindings in myLeoSettings.leo
>   tree Tab focus-to-body
>all Tab indent-region
>   text Tab newline-and-indent
> Leo 6.1-devel, devel branch, build 4e9d54b82e
> 2019-09-30 17:09:04 -0500
> leo_excepthook Uncaught Python exception: [WinError 3] The system cannot
> find the path specified:
> 'D:/bin/chocolatey/lib/python3/tools/lib/site-packages/leo/scripts/scripts.leo'
>
> NoneType: None
>
>
> E:\git\leo-editor>python --version
> Python 3.7.4
>
>
> CLI args are sufficient.
> This can definitely be caused by python version upgrade (seems like that
> path points to old python's path) - but got no idea how.
> Leo installed with PIP works fine.
> Version from git launched ok before I pulled the changes.
>
> --
> 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/6ea068e0-1e25-4192-b546-5cf4ceb4b479%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/CAO5X8Cyvwz7OH2%2BJzcbc3xhoA0B-gEHkNajoEabvKBe25y%2BeNQ%40mail.gmail.com.

Re: How to trace Leo Core?

[Brian Theado]

Edward can speak to the built-in leo traces, but there are also other
options.

I mentioned in the thread at
https://groups.google.com/forum/#!topic/leo-editor/r6ktpQNWySk, about using
the python trace module for debugging python applications, but I no longer
recommend using it because it is too difficult to filter out noise. Since
then I've discovered https://github.com/ionelmc/python-hunter and it is
excellent. You can filter exactly which modules do and don't get traced and
the colorized output looks nice.

Depending on what pattern of modules you pick to trace you will still get a
firehose of information. You can either fine-tune your python-hunter
queries more or just save the trace output to a file which you can search
through.

But sometimes the approach Edward advocates in the above thread of
modifying the code yourself and adding traces and using clones will be
better. It's wise to heed his caution about signal to noise ratio :-).

Here is an example python hunter trace I've run on leo (after pip install
hunter):

PYTHONHUNTER="module='leo.core.leoApp'" HOME=$HOME/tmp/blank
../pyqt-3.7-venv/bin/python launchLeo.py ~/tmp/new.leo


Here are some more example trace queries I've used:

PYTHONHUNTER="module_in=['leo.core.leoApp', 'leo.core.leoNodes']"
PYTHONHUNTER="~Q(kind='line'),module_in=['leo.core.leoApp',
'leo.core.leoNodes']"
PYTHONHUNTER="Q(module_startswith='leo')"


Here, I redirect to the pager program 'less' and do it in such a way as to
not lose the color. By using less, I can search through the results
(leo-bridge-test.py is just a file I was using to learn about leo bridge).

PYTHONHUNTER="Q(module_startswith='leo'),action=CallPrinter(force_colors=True)"
HOME=$HOME/tmp/blank ../pyqt-3.7-venv/bin/python  leo-bridge-test.py 2>&1 |
less -R


Not sure this is really what you are after, but I thought I'd share in case
in helps.

Brian


On Sun, Sep 29, 2019 at 3:43 PM Viktor Ransmayr 
wrote:

> Hello Edward,
>
> I tried to find out, if I can enable 'auditing/ tracing' for Leo in order
> to 'visualize' the run-time behavior of Leo Core ...
>
> I started with something, that I thought should/ would be an easy starting
> point: I tried to audit/ trace what happens, when Leo opens an empty
> outline in a PyVE using:
>
> * (Leo) PS C:\Users\Viktor\PyVE\PyPI\Leo\Lib\site-packages\leo\core>
> ./runLeo.py --trace=plugins ~/empty.leo
>
> The result (Log-001) was not that helpfull. - Am I missing something?
>
> With kind regards,
>
> Viktor
>
> ---
>
> 
>
> Leo Log Window
> Leo 6.0-final
> Python 3.7.4, PyQt version 5.13.0
> Windows 10 AMD64 (build 10.0.18362) SP0
> current dir: C:/Users/Viktor/PyVE/PyPI/Leo/Lib/site-packages/leo/core
> load dir: C:/Users/Viktor/PyVE/PyPI/Leo/lib/site-packages/leo/core
> global config dir:
> C:/Users/Viktor/PyVE/PyPI/Leo/lib/site-packages/leo/config
> home dir: C:/Users/Viktor
> reading settings in
> C:/Users/Viktor/PyVE/PyPI/Leo/lib/site-packages/leo/config/leoSettings.leo
> reading settings in C:/Users/Viktor/.leo/myLeoSettings.leo
> loadOnePlugin: loaded: leo.plugins.plugins_menu
> loadOnePlugin: loaded: leo.plugins.mod_scripting
> loadOnePlugin: loaded: leo.plugins.viewrendered
>
> 
>
> --
> 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/c89b189a-5aec-48d8-b312-65cba932a850%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/CAO5X8Cwg065h3NW1_XLs10ALJMaAzmm9Wf%3DJyqOchfON9Cd5Ng%40mail.gmail.com.

Re: New plugin history_tracer

[Brian Theado]

Thanks. It worked for me. Looks just as impressive as your demo a few
months back. Nice work!

On Sat, Sep 28, 2019 at 4:17 PM vitalije  wrote:

> Good catch. I forgot to add it.
> Rev d8fc8bc
> 
>  contains
> the plugin.
>
> On Saturday, September 28, 2019 at 10:10:03 PM UTC+2, btheado wrote:
>>
>> Vitalije,
>>
>> I'm see a blank @file history_tracer.py. Did you forget a 'git add'?
>>
>> Brian
>>
>> On Sat, Sep 28, 2019 at 2:22 PM vitalije  wrote:
>>
>>> I finally got around to pack and publish my new plugin history_tracer.
>>>
>>> In order to be useful one must have installed leo-ver-serv utility. I'll
>>> try to make it available as a binary file for Ubuntu 18.04 and Windows 10.
>>>
>>> It should be straightforward to install from source if one already has
>>> installed cargo, a Rust building and package management tool.
>>>
>>> Here 
>>> is described how to install cargo. If you have cargo installed then
>>> installation of leo-ver-serv would be quite easy.
>>> cargo install leo-ver-serv
>>>
>>> For Ubuntu 18.04 pre-built binary can be found here
>>>  size 9.2M, sha1sum:
>>> .9ca502f10ad4c35b1f538a0a1dbfe17ad4724155.
>>>
>>> After installation, leo-ver-serv should be run with the following
>>> command:
>>>
>>> leo-ver-serv ~/.leo/.leoRecentFiles.txt 8087
>>>
>>> The first argument should be a filename of a file containing list of
>>> absolute paths to known Leo files. One suitable file that can be used is
>>> ~/.leo/.leoRecentFiles.txt which contains list of recently used Leo files.
>>> Only files whose names are listed in this file will have their history
>>> tracked. The second argument is a port number. The same port number must be
>>> in your settings @int history-tracer-port which by default has value 8087.
>>>
>>> Once you have leo-ver-serv running, you can start Leo and every time you
>>> are inactive for more than 5 seconds, history_tracer plugin will send a
>>> snapshot of current outline to leo-ver-serv and that version will be
>>> recorded. If you wish to see previous versions you can open:
>>> http://localhost:8087/ in your browser.
>>>
>>> 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/761e1d6a-8dab-4af8-b048-c2a5a503af29%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/746cb984-8185-4973-abb2-420531bf4a2c%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/CAO5X8CyV81xAW4T-f5tEn6nKYb5FpFurJYoWHL%2BwrXS8GoKZfA%40mail.gmail.com.

Re: New plugin history_tracer

[Brian Theado]

Vitalije,

I'm see a blank @file history_tracer.py. Did you forget a 'git add'?

Brian

On Sat, Sep 28, 2019 at 2:22 PM vitalije  wrote:

> I finally got around to pack and publish my new plugin history_tracer.
>
> In order to be useful one must have installed leo-ver-serv utility. I'll
> try to make it available as a binary file for Ubuntu 18.04 and Windows 10.
>
> It should be straightforward to install from source if one already has
> installed cargo, a Rust building and package management tool.
>
> Here 
> is described how to install cargo. If you have cargo installed then
> installation of leo-ver-serv would be quite easy.
> cargo install leo-ver-serv
>
> For Ubuntu 18.04 pre-built binary can be found here
>  size 9.2M, sha1sum:
> .9ca502f10ad4c35b1f538a0a1dbfe17ad4724155.
>
> After installation, leo-ver-serv should be run with the following command:
>
> leo-ver-serv ~/.leo/.leoRecentFiles.txt 8087
>
> The first argument should be a filename of a file containing list of
> absolute paths to known Leo files. One suitable file that can be used is
> ~/.leo/.leoRecentFiles.txt which contains list of recently used Leo files.
> Only files whose names are listed in this file will have their history
> tracked. The second argument is a port number. The same port number must be
> in your settings @int history-tracer-port which by default has value 8087.
>
> Once you have leo-ver-serv running, you can start Leo and every time you
> are inactive for more than 5 seconds, history_tracer plugin will send a
> snapshot of current outline to leo-ver-serv and that version will be
> recorded. If you wish to see previous versions you can open:
> http://localhost:8087/ in your browser.
>
> 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/761e1d6a-8dab-4af8-b048-c2a5a503af29%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/CAO5X8CwK7pfMTZxLv6C6YFZMZxMiQ5j1qcNRqPciW%3DFfUDK1Vg%40mail.gmail.com.

Re: Pytest command

[Brian Theado]

Vitalije,

This looks nice. I'm really impressed with the assertion failure output
pytest gives.

I wonder how hard it would be to write a pytest plugin to support leo's
unit tests. Their plugin system makes use of hooks like Leo does, only it
is like hooks on steroids.

This example code shows how tests can be collected from a yaml file instead
of python code:
https://docs.pytest.org/en/latest/example/nonpython.html#yaml-plugin.
Writing code to get tests from unittest.leo might be similarly
straightforward.

https://docs.pytest.org/en/latest/writing_plugins.html
https://docs.pytest.org/en/latest/plugins.html#using-plugins
https://docs.pytest.org/en/latest/reference.html#collection-hooks
https://pluggy.readthedocs.io/en/latest/

That's quite an impressive plugin system pytest has.

Brian


On Thu, Sep 26, 2019 at 6:31 AM vitalije  wrote:

> Hm, looking in the output it seems that the name of the test node, and
> failed test function in the output are missed. Revision 064e218
>  fixes this. Now the
> output is like:
>
> ---example/test_a failed-
> assert 4 == 4.1
>  +  where 4 = inc(3)
> ---example/test_b failed-
> assert 18.297 == 18
>  +  where 18.297 = times_3(6.1)
>  +where 6.1 = add_2(4.1)
>  +  where 4.1 = inc(3.1)
>  +  and   18 = times_3(6)
>  +where 6 = inc(5)
> failed:2 tests
>
> 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/b7880eb4-9c2f-4d37-932d-d1f0d72fcfe3%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/CAO5X8Cx6ygFDRqGgXgb%2BmPnFM5Ow34qWr41Y%3DS0rgdcjT7ksmw%40mail.gmail.com.

Re: Automatically move to the beginning/end of line

[Brian Theado]

Thanks a lot, Edward! I'll give it a try later.

I discovered when using my code on a mac laptop that I had to bind to
Keypad-Up and Keypad-Down. Apparently the laptop keyboard on my mac doesn't
have any keys mapping to just plain Up and Down.

On Thu, Sep 26, 2019 at 12:10 PM Edward K. Ream  wrote:

> On Thursday, September 26, 2019 at 8:51:02 AM UTC-5, Edward K. Ream wrote:
>
> > I'll add these commands later today to Leo's core, and add do-nothing
> entries for the new commands to leoSettings.leo.
> > See #1353 .
>
> Completed at 2d736a in devel.
>
> 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/dbc6a4ca-848d-4093-8016-e0a0dbdaa742%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/CAO5X8CyPvseJ_JcrO3MaESyfvi5sdWcgaOKxvC8cAd8%3Dx3t%2BKA%40mail.gmail.com.

Re: Automatically move to the beginning/end of line

[Brian Theado]

Yes, I've always noticed this behavior from Leo and rather than look into
fixing it, I've trained myself when using leo to select one fewer lines
than needed before I hit the tab key to indent. Maybe it isn't all that
hard to fix it, but maybe some people don't see this behavior as "broken".
I think it is because the cursor is on the line (even though nothing on
that line is highlighted for selection). The indentation code probably
operates on all the lines with selection as well as the line with the
cursor.

On Thu, Sep 26, 2019 at 9:44 AM gar  wrote:

> 1. move cursor to the beginning of the line
> 2. press shift and up twice
> 3. press tab
> 4. enjoy with how first not selected line is idented
>
> чт, 26 сент. 2019 г. в 16:41, Edward K. Ream :
>
>>
>>
>> On Thu, Sep 26, 2019 at 8:16 AM gar  wrote:
>>
>>> Thanks for that, Brian! Exactly what is required!
>>>
>>> By the way, recently I discovered another oddness.
>>> When you select several lines at the moment and try to ident/deident
>>> them by a single 'tab' or 'ctrl->` - the line above/below the cursor is
>>> also affected.
>>>
>>
>> I haven't seen this.  I suspect this happens only when the lines are
>> continued.
>>
>> 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/CAMF8tS2E238cHxtThs0%2B-K3yWCSAr9Xa-9BOUx6BhXw7tsYh_g%40mail.gmail.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/CAC%2B8SVxOTcDNY0_eGo4P_nRZahOhCe9fQ0AQyA8uMshoZx5s2Q%40mail.gmail.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/CAO5X8CxsRiEFB4BOHuLX2byMPVyMvguBqSjo6mf6TL2TXJ_2cg%40mail.gmail.com.

Automatically move to the beginning/end of line

[Brian Theado]

When moving down a text editor line-by-line, I rely on the common behavior
of automatically moving to the end of the line when trying to scroll down
past the last line. Similar for when scrolling up past the first line. Leo
doesn't have this behavior, so I wrote the below script. Thought I'd share
in case anyone else finds it useful.

@settings->@shortcuts:
previous-or-beginning-of-line ! text = Up
next-or-end-of-line ! text = Down
previous-or-beginning-of-line-extend-selection ! text = Shift-Up
next-or-end-of-line-extend-selection ! text = Shift-Down


@script

def lineScrollHelper(c, prefix1, prefix2, suffix):
w = c.frame.body.wrapper
ins = w.getInsertPoint()
c.inCommand = False
c.executeMinibufferCommand(prefix1 + 'line' + suffix)
ins2 = w.getInsertPoint()

# If the cursor didn't change, then go to beginning/end of line

if ins == ins2:
c.executeMinibufferCommand(prefix2 + 'of-line' + suffix)

@g.command('next-or-end-of-line')
def nextOrEndOfLine(event):
lineScrollHelper(event['c'], 'next-', 'end-', '')

@g.command('previous-or-beginning-of-line')
def previousOrBeginningOfLine(event):
lineScrollHelper(event['c'], 'previous-', 'beginning-', '')

@g.command('next-or-end-of-line-extend-selection')
def nextOrEndOfLineExtendSelection(event):
lineScrollHelper(event['c'], 'next-', 'end-', '-extend-selection')

@g.command('previous-or-beginning-of-line-extend-selection')
def previousOrBeginningOfLineExtendSelection(event):
lineScrollHelper(event['c'], 'previous-', 'beginning-',
'-extend-selection')

-- 
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/CAO5X8CyVRMJ%2BO0tU%3D-7MAm6qhsELhj3kV4N8X33YOh2EL%3DuhEg%40mail.gmail.com.

Re: Devs, please don't add commit_timestamp.json

[Brian Theado]

Maybe vitalije still has the old git hook:

$ git log -- leo/core/commit_timestamp.json
[...]

commit 65ca5ec3d4a3af17c538026d825fcea782eb5b8a
Author: vitalije 
Date:   Mon Sep 23 08:17:05 2019 +0200
Fixed issue #658

Leo build: 20190923061705


On Mon, Sep 23, 2019 at 7:16 AM Edward K. Ream  wrote:

> Somebody added this file recently.  I suspect it was Matt.
>
> This happens if you are using an old git hook.  Please delete them if
> necessary from leo-editor.git.hooks.
>
> 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/5632f465-69a6-42c4-9391-2727ca408c97%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/CAO5X8CyX3Pk-CRST9157nucp7FZ9AaxMsLKJz_hf1B%2BmOBPS1Q%40mail.gmail.com.

Re: Unpredictable bug: "NewHeadline" instead of actual headline

[Brian Theado]

Without seeing actual code, I find it difficult to understand your
explanation enough to come up with any guess. But it seems you have 3
things: leo code, your comparison code, and your unit test code. Since this
problem started happening, at least one of those things had to have changed
right? I see you are running a git commit from a month ago, so maybe your
leo code hasn't changed since the problem appeared and so it must be your
unit test or program code? Do you have a history (in git or something) of
your code? When it is a problem which is fairly easy to reliably reproduce
then git bisect is very handy.

It isn't clear from your description what your 2nd subprocess.call is
executing. Whatever it is, maybe you can have extra tracing or set a
debugger breakpoint whenever newHeadline is seen and that way you can get
more information.

On Thu, Sep 19, 2019 at 6:02 PM SegundoBob  wrote:

>
> *Leo-Editor Version:*
> Leo 6.1-devel, devel branch, build f5986d8016
> 2019-08-09 10:23:41 -0500
> Python 3.6.8, PyQt version 5.11.1
>
> *Bug Description:*
>
> This bug may be in my code or in Leo-Editor code.  I have been seeing
> occurrences for at least two weeks.
>
> The bug occurs when I run my unit tests for my program that compares two
> Leo-Editor files.  I have 41 unit tests.  The bug occurs about once every
> 30 tests.
>
> My comparison program uses LeoBridge to access Leo-Editor files.  File
> "Content" as accessed by vnode (not position).  File "structure" is
> analyzed by position (path).  That is, my program gets the headline and
> body from the vnode (vn.h, bn.b).  When my comparison program compares the
> unit test File A and File B, the bug never occurs.  Using LeoBridge my
> comparision program produces a difference file (File D).  The unit tests
> use subprocess.call() to execute my comparision program, so the process
> comparing File A and File B and producing File D ends.  Then the unit tests
> use subprocess.call() to compare the actual File D with the expected File
> D.  This is when the bug occurs.
>
> The bug is always that a headline in File D, is seen to be "NewHeadline."
> But when I look at File D, there is no "NewHeadline" and File D is exactly
> as expected.
>
> There are never two or more bug occurrences in comparing one File D.  The
> bug never occurs on a node body.  There is a slight tendency for bug
> occurrences to cluster.  That is, sometimes it occurs on two tests in a row
> or even three tests in row.
>
> *Help:*
>
> Does anyone have any ideas about how this bug could occur?  Does anyone
> have any ideas about how to chase this bug?
>
> --
> 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/fd49a5e7-6694-4bf6-9b22-88c517ef38ef%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/CAO5X8CzxvJ32vuYGr%3DfqXh0quQi22xxZYQuUQX6AyeH7p7SR2Q%40mail.gmail.com.

Re: Automatic git commit on save using entr

[Brian Theado]

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

[Brian Theado]

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

[Brian Theado]

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: Automatic git commit on save using entr

[Brian Theado]

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.

Automatic git commit on save using entr

[Brian Theado]

I'm currently using leo as my main note-taking application and I find it
very useful to have auto-saving, so I enabled the auto-save module.

I felt a little nervous about using auto-save and decided I wanted a git
commit on every save so I would have a history in case anything goes wrong.

I read Vitalije's post from not too long ago about overriding the ctrl-s
key to perform extra actions, but with auto-save I'm not using any
keystrokes. I decided to use the 'entr' utility (http://entrproject.org -
which I learned about on this list a long time ago) to watch for changes to
my .leo file and automatically execute a git commit.

I use an @script script in my leo outline to launch the entr process in the
background and it is working great. I did encounter one problem with the
entr process out-living the leo process. IOW, it doesn't exit when leo
exits. So then when I launch leo again I have two entr processes running,
both of which are trying to run auto git commits.

To work around that problem, I found a way to ensure a 2nd instance of that
process doesn't get launched if it is already running and I'm satisfied
with it. It doesn't solve the issue of the entr process out-living leo, but
it solves the more serious concern of having two instances competing with
each other. It would have been better if instead (or in addtion), I would
have found a way to get the pid of the backround entr process and kill it
when leo exits. But as I said, I'm satisfied enough for now with what I
have.

Here is the (linux only) script code (assumes the 'git init' has already
been run in the directory with the leo file and the leo file has been
commited once):

# The ampersand is special syntax for leo to execute the command
# in the background. The "flock ... 9>" part is because when leo
# exits, the background process doesn't get cleaned up and this
# flock "incantation" will prevent a second instance from launching
# see http://man7.org/linux/man-pages/man1/flock.1.html
# The flock utility is Linux only.
# The 'entr' utility (http://entrproject.org) will watch the given list
# of filenames and run the commands whenever changed
g.execute_shell_commands(
f"""&(
flock -n 9 || exit 1
ls {c.fileName()} | entr -s 'git diff . | cat
git commit -m "$(date +%Y-%m-%d) autocommit" .'
) 9> {c.fileName()}.entr.lock
"""
)


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/CAO5X8CyruizJRFHk-woZWHKn_Fz5a0T1gy5vBX9TivJ42rWv8w%40mail.gmail.com.

Re: Global variables in user scripts

[Brian Theado]

Thanks, Vitalije. Only after seeing your response did it occur to me to
take a closer look at the scripting docs and of course the user_dict ivar
is documented there.

On Wed, Sep 11, 2019 at 7:42 AM vitalije  wrote:

> You have c.user_dict for these kind of things. It is an ordinary python
> dictionary and you can put in it anything you want. Values you set in this
> dictionary will be there until Leo exits. If you need to make them more
> permanent then you can put values in c.db (looks like and behaves like a
> dictionary, but values must be pickleable).
>
> Vitalije
>
> On Wednesday, September 11, 2019 at 1:28:39 PM UTC+2, btheado wrote:
>>
>> I'm writing a script button in which I want to transform some outline
>> data into html and then display that html in a leo doc. The viewrendered
>> functionality doesn't seem to really fit my needs as the render pane output
>> is tied to whatever node is currently selected.
>>
>> I just want to be able to display the html "on-demand" (i.e. through
>> script button click) and refresh it on-demand.
>>
>> I have working code for it, but it requires storing the dock object
>> somewhere so it can be used again the next time the script is called. I was
>> wondering if there is some good, already-established convention for storing
>> "global" state for scripts.
>>
>> In my case, the variable makes sense to be on a per-commander basis, so I
>> just stored my information on the commander 'c'. That doesn't seem very
>> clean to me and I was wondering if there is a better approach?
>>
>> Here is my function which stores and uses global state on c:
>>
>> def display_widget_in_leo_pane(c, w, name):
>> """
>> w is the widget to display
>> name is the name the widget should appear in pane menu
>> """
>> dw = c.frame.top
>> if not hasattr(c, '*my_docks*'): c.my_docks = {}
>> dock = c.*my_docks*.get(name)
>> if not dock:
>> dock = g.app.gui.create_dock_widget(
>>  closeable=True, moveable=True, height=50, name=name)
>> c.*my_docks*[name] = dock
>> dw.addDockWidget(QtCore.Qt.RightDockWidgetArea, dock)
>> dock.setWidget(w)
>> dock.show()
>>
>>
>> And a function to use the above:
>>
>> def display_html(html, name = 'test html'):
>> w = QtWidgets.QTextBrowser()
>> w.setHtml(html)
>> display_widget_in_leo_pane(c, w, name)
>>
>> Also, could someone comment on whether the above code is "leaking"
>> widgets? Should I be calling dock.widget() to retrieve the old widget each
>> time to perform some sort of delete/cleanup?
>>
>> 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/39d49062-9e58-402d-9a97-bd98ed090441%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/CAO5X8CwqLZybR5dyZEKU94%2BhJBQ9GjUDRGxc8Z-do3eDXdhAVw%40mail.gmail.com.

Global variables in user scripts

[Brian Theado]

I'm writing a script button in which I want to transform some outline data
into html and then display that html in a leo doc. The viewrendered
functionality doesn't seem to really fit my needs as the render pane output
is tied to whatever node is currently selected.

I just want to be able to display the html "on-demand" (i.e. through script
button click) and refresh it on-demand.

I have working code for it, but it requires storing the dock object
somewhere so it can be used again the next time the script is called. I was
wondering if there is some good, already-established convention for storing
"global" state for scripts.

In my case, the variable makes sense to be on a per-commander basis, so I
just stored my information on the commander 'c'. That doesn't seem very
clean to me and I was wondering if there is a better approach?

Here is my function which stores and uses global state on c:

def display_widget_in_leo_pane(c, w, name):
"""
w is the widget to display
name is the name the widget should appear in pane menu
"""
dw = c.frame.top
if not hasattr(c, '*my_docks*'): c.my_docks = {}
dock = c.*my_docks*.get(name)
if not dock:
dock = g.app.gui.create_dock_widget(
 closeable=True, moveable=True, height=50, name=name)
c.*my_docks*[name] = dock
dw.addDockWidget(QtCore.Qt.RightDockWidgetArea, dock)
dock.setWidget(w)
dock.show()


And a function to use the above:

def display_html(html, name = 'test html'):
w = QtWidgets.QTextBrowser()
w.setHtml(html)
display_widget_in_leo_pane(c, w, name)

Also, could someone comment on whether the above code is "leaking" widgets?
Should I be calling dock.widget() to retrieve the old widget each time to
perform some sort of delete/cleanup?

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/CAO5X8CyrW7Uy7aaN_eMPiHu3FR1ay3o8PVAgLRb7OmGzscPRZw%40mail.gmail.com.

Re: Please test the docks branch

[Brian Theado]

I found some strange behavior when launching leo with a non-existent file
on the command line. If I don't give any files on the command line or if I
give the path to an existing file, then it is fine. But with the new file
on command line, the tips windows appears and leo is still running, but
there is no other window and I can only exit by hitting ctrl-c. This is on
linux.

I used git bisect and found the bad behavior is introduced by
commit 313f9e99af.

Let me know if you can't reproduce the issue and I can help more.

On Fri, Sep 6, 2019 at 10:28 AM Edward K. Ream  wrote:

>
>
> On Fri, Sep 6, 2019 at 8:33 AM Edward K. Ream  wrote:
>
>> The docks branch improves how Leo handles docks. This is #1318
>> .
>>
>> - Bug fix: The VR pane is moveable whenever --init-docks is in effect.
>> - The `@bool` @bool use-vr-dock  is no longer used.
>> - The VR pane is hidden for new windows.
>>
>> The code changes are small, but this code must be considered experimental.
>>
>
> I have just merged docks into pyzo (not devel). All seems well.
>
> *Important*: Leo will use the dock layout in the first loaded .leo file
> for new windows.  So if you don't want all of pyzo's docks in new windows,
> hide them in your first-loaded .leo file.
>
> 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/CAMF8tS1FYozr4BENU%3Dp-N9nLjqhMTFwWTCp%2BCfzf%2BuQMQbLBeg%40mail.gmail.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/CAO5X8CxRWJAEbPrkNNXndvR99bkgB0418SE1G4reL4eO5tn11Q%40mail.gmail.com.

Re: Active settings outline: status report

[Brian Theado]

On Sun, Sep 1, 2019 at 6:13 AM vitalije  wrote:

> I am tempted to put aside all my current tasks and write my own
> launchLeo.py which will monkey patch completely cofiguration code and just
> read settings from the database table. I guess it would greatly reduce
> number of code lines that has to be executed every time Leo opens new
> commander.
>

Very slightly related to this, I was playing around and discovered leo can
be started without reading any .leo files at all. Just delete
config/leoSettings.leo and then run it like this:

HOME=$HOME/tmp/blank python launchLeo.py ~/tmp/new.leo


where ~/tmp/new.leo is a non-existing file (so no settings are are read
from it) and $HOME/tmp/blank doesn't have any myLeoSettings.leo.

Surprisingly leo almost works when launching like this. There are no menus
or keystrokes or right click menus, but mouse clicks work and you can mouse
click onto the minibuffer and run commands. However outline modifications
(i.e. insert-node) cause a core dump with this python stack dump:

Traceback (most recent call last):
  File "/home/btheado/src/leo-editor/leo/plugins/qt_frame.py", line 3369,
in tab_callback
c.findCommands.startSearch(event=None)
  File "/home/btheado/src/leo-editor/leo/core/leoFind.py", line 596, in
startSearch
self.openFindTab(event)
  File "/home/btheado/src/leo-editor/leo/core/leoFind.py", line 531, in
openFindTab
g.app.gui.openFindDialog(c)
  File "/home/btheado/src/leo-editor/leo/plugins/qt_gui.py", line 209, in
openFindDialog
d.setStyleSheet(c.active_stylesheet)
AttributeError: 'Commands' object has no attribute 'active_stylesheet'

I'm able to get this same crash by just clicking on the find tab's tab. It
seems strange outline modification causes openFindTab to be called.

While this is likely not a valid mode to be running leo, maybe it does
point to some actual issue?

I'm surprised it causes core to be dumped.

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/CAO5X8CxHGksfouPOTH27ORmQYmZpntmB95m95zueybiQQoqWpA%40mail.gmail.com.

Re: I've just killed two issues

[Brian Theado]

Vitalije,

On Mon, Aug 26, 2019 at 3:42 AM vitalije  wrote:

> Do you envision distributing the leoSettings.leo derived database with leo
>> itself? Or do you have something else in mind? I was wondering how that
>> first database of settings would be available at the time of leo first use.
>>
>
> Leo defaults contained in leoSettings.leo should be distributed in their
> "pre-compiled" form. For example it could be one python module containing
> one big tuple of tuples representing the initial content of db. On start if
> this db doesn't contain table settings, table will be created and populated
> with the default values from this python module. This action is executed
> only once and it takes negligible time. For new users the result would be
> exactly the same as if they installed Leo and run it for the first time
> before they created myLeoSettings.leo.
>

Sounds reasonable and it would probably also be possible to have a
"compile-settings" command line option for leo which could be used in place
of the "open myLeoSettings.leo and save it again" you mentioned.

About 10 years ago I worked on some server software we wrote in C. The
configuration was controlled via a complicated set of sqlite tables. They
were complicated because it was a structure which made it easier for the
end-user configuration UI. We decided to have the C code initialization
structure be as simple as possible. We kept the complexity of transforming
the complicated structure to the simple structure far away from the
harder-to-change C code. This decision was very helpful. It resulted in
fewer changes to the C startup code and the changes we couldn't avoid were
made on simpler code. The simpler structure would have been onerous for the
user to construct, but the data transformation took care of hiding that
difficulty from the user. Having the transformation separate from the
server code, it also made it much easier to troubleshoot.

I see the leo situation as somewhat analogous. The settings-in-outlines is
easier for the user to deal with just like the complicated sqlite tables
were easier for our configuration users, and the settings db you propose is
easier for the code to deal with just as our simplified C structure was for
our server software. Data transformations can be useful!

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/CAO5X8CzK4nhaK61%3DgzPnaMDmsH4dFWO%3DrbDX91iuOguqSvx0VQ%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

It turns out the '-m pdb' workaround for the readline crash does work for
me running unit tests.

I decided I wanted to follow the good practice of adding a failing unit
test which exposes the bug and then show after the fix that same test
passes. I discovered there are already unit tests for other group undo
commands like convertAllBlanks and convertAllTabs and I wondered how those
tests were passing. It turns out all the undo/redo tests start with a fresh
undo stack. The off-by-one error of this bug causes the bead index to be -1
instead of 0. But for a single element list array, indices -1 and 0 point
to the same list element. So the group redo will always function properly
when it is the only item on the list.

In order to duplicate the bug, I will need to write a test containing
multiple commands. I might be out of time for this for a few days, but I
plan to tackle it when I get a chance.

On Wed, Aug 21, 2019 at 7:45 AM Brian Theado  wrote:

> Sure, I'll do that or figure out the segfault issue sometime this week.
>
> On Tue, Aug 20, 2019 at 7:26 AM Edward K. Ream 
> wrote:
>
>> Unfortunately, I'm not able to run unit tests without getting a segfault.
>>>
>> Alright.  Create a new branch, and I'll run the unit tests there.
>>
>

-- 
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/CAO5X8Cxs_P3MHsYWw1eKC9tSNZug9XexBPezsOk0aR%2BqBt7mVQ%40mail.gmail.com.

Re: Invalid position error on redo position move

[Brian Theado]

Vitalije,

On Wed, Aug 21, 2019 at 5:41 PM vitalije  wrote:

> Well I didn't tried too hard to make it more readable. It can be improved.
>

Ok, after looking at it some more, I see that the vnode tree structure
involves only a list of children and a list of parents (one parent for each
clone). That's pretty straight forward and I added a few comments and it
seems plenty readable. I was able to change the code (without breaking it!)
so it creates the day node at the second position instead of the last
position. That is an important feature for me.


> But changing tree using vnodes has several benefits. First of all, vnodes
> are stable (immune to tree changes) - positions are not.
>

And I think this is what appeals the most to me.  With the position code, I
tried to factor out some common code, but it took two positions as input
(saved positions issue!) and for one of the cases I was using it, one of
the positions got invalidated. I suspect if I try to factor out some of the
vnode code in a similar way, it won't be as fragile as that.


> The second they work much faster because every change in the tree
> performed through positions are followed by a redraw and a lot of code that
> doesn't need to be executed until the complete tree change is done. You
> don't usually want to see intermediate versions of tree. You want to see
> the finished tree. When making changes using vnodes, nothing is redrawn
> until you explicitly call `c.redraw()`.
>

I took a quick look through the vnode code and only saw the redraw for .h
and .b changes, but not for the tree structure changes. Is that what you
are referring to or was there something else I missed?

 [...]

> The function make_snapshot creates a snapshot of data needed to recreate
> subtree structure. In the variant where no changes to headlines nor bodies
> are made, this function takes enough data to undo the changes. However if
> you need to keep record of headlines and bodies too, then you should add
> them too to snapshot. Of course  in that case you must change the function
> from_snapshot too.
>

Got it, thanks.

[...]

> This two functions can store and recreate the exact copy of the given
> vnode. If you want to make snapshot of the whole outline, pass the
> c.hiddenRootNode as the argument to the make_snapshot function. However, if
> you are certain that the only changes made are under one vnode (for example
> @ftlist node), then it is more efficient to store only subtree of @ftlist.
>

Thanks a lot for your help.

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/CAO5X8Cy_37DQ0ZXT%3D6Bs%2BO7q9-9B2g-s9hC9Vmfhn7HjXF-nWQ%40mail.gmail.com.

Re: Invalid position error on redo position move

[Brian Theado]

Thanks vitalije for noticing the position error. I wonder why it only gave
an error on redo and not also for the original operation.

Thanks for the vnode-based code. Based on a quick test, it seems better
than my position based code as I haven't seen any errors on undo/redo.

I'm finding the vnode code harder to read, but if it works better then it
is better :-). However, is it better because you are the one who wrote it
instead of me :-), or because it is easier to avoid mistakes using vnodes?
I'll take a close look at it and add the insert functionality I also had in
my code. Maybe that way I will if/how out how vnodes help avoid the
mistakes.

About this comment:
# if you need to keep track of headlines and boides too
# yield v, tuple(v.children), tuple(v.parents), v.h, v.b

Does that only mean if headlines and bodies are changing that the above
needs to be done?

On Wed, Aug 21, 2019, 1:35 PM vitalije  wrote:

> Well after `one_clone = one.clone()`, position `three` becomes invalid,
> because `one.clone()` inserts cloned node above the node `three`. If you
> add:
> three._childIndex += 1
>
>
> after `one_clone = one.clone()`, there will be no error after executing
> script.
>
> If I were you I would make all tree changes using v-nodes, and for making
> things undoable I would create my own undoHelper and redoHelper. Here is
> for example one of your scripts that we have discussed before:
>
> import time
> import leo.core.leoNodes as leoNodes
> def findFtlistAncestor(p):
> p = p.copy()
> while p and not p.h.startswith('@ftlist'):
> p = p.parent()
> return p
>
>
> def moveToTopAndCloneToAtDay(c, p):
> """
> Move the node identified by position p to the first child of
> an ancestor @ftlist node and also clone it to a sibling @day
> node with date matching today's date
> """
> ftlist = findFtlistAncestor(p)
> if not ftlist:
> g.es("Not in ftlist tree")
> return {}
> vft = ftlist.v
> before = make_snapshot(vft)
> v = p.v
> if vft in v.parents:
> i = vft.children.index(v)
> del vft.children[i]
> vft.children.insert(0, v)
> else:
> vft.children.insert(0, v)
> v.parents.append(vft)
> today = "@day " +  time.strftime("%Y-%m-%d", time.gmtime())
> for i, ch in enumerate(vft.children):
> if ch.h == today:
> break
> else:
> i = len(vft.children)
> ch = leoNodes.vnode(c)
> ch.h = today
> vft.children.append(ch)
> ch.parents.append(vft)
> if ch in v.parents:
> i = ch.children.index(v)
> del ch.children[i]
> ch.children.insert(0, v)
> else:
> ch.children.insert(0, v)
> v.parents.append(ch)
> return ftlist, before, make_snapshot(vft)
>
>
> def from_snapshot(data):
> for v, children, parents in data:
> v.children[:] = children
> v.parents[:] = parents
>
>
> def make_snapshot(v0):
> def it(v):
> yield v, tuple(v.children), tuple(v.parents)
> # if you need to keep track of headlines and boides too
> # yield v, tuple(v.children), tuple(v.parents), v.h, v.b
> for ch in v.children:
> yield from it(ch)
> return tuple(it(v0))
>
>
> def do_change():
> undo_data = c.undoer.createCommonBunch(p)
> undo_data.kind = 'my-special-operation'
> undo_data.undoType = 'my-special-operation'
> ftlist, before, after = moveToTopAndCloneToAtDay(c, p)
> undo_data.before = before
> undo_data.after = after
> undo_data.ftlist = ftlist
> undo_data.undoHelper = lambda:from_snapshot(undo_data.before) or c.
> redraw(undo_data.p)
> undo_data.redoHelper = lambda:from_snapshot(undo_data.after) or c.
> redraw(undo_data.ftlist.firstChild())
> c.undoer.pushBead(undo_data)
> c.redraw(ftlist.firstChild())
>
> do_change()
>
> If you make a script button of this code, you can try your action and its
> undo/redo functionality on some of the descendants of your @ftlist tree.
>
> 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/20942315-145c-4dff-83ea-d0b6a1a39afe%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/CAO5X8CwDc1PwdXbpWe0yZMuC9fSy_ZcsXP4W1U_srRzfeMJhhA%40mail.gmail.com.

Re: Invalid position error on redo position move

[Brian Theado]

Thanks, vitalije. The else part of the 'if 1:' was my failed attempt to
further simplify the failing case.

The error is happening when the code does: insert, clone, move the clone to
the first child of node="two" (which already has one child named "three"),
undo, redo.

I though I might also duplicate it by skipping the insert and just cloning
the already existing node="one". But still I want to move the clone to the
first child of "two". Since the insert was skipped, one fewer moveToNext()
was needed in order to get the to new parent node="two".

The error given by the code as currently written is what I need to solve.
You can ignore the else clause it is just noise :-).

Actually, inspired by your response, I found a way to duplicate the error
even without the insert. So now it is just clone, move, undo, redo. Here is
the new subtree xml:



http://leoeditor.com/namespaces/leo-python-editor/1.1;
>


redo bug (use ctrl-b)
one
two
three
four




@language python

# Code written to assume this descendent structure
# one
# two
# three
#   four
parent = p; u = c.undoer

one = parent.copy().moveToFirstChild()
three = one.copy().moveToNext().moveToNext()

undoData = u.beforeCloneNode(one)
one_clone = one.clone()
u.afterCloneNode(one_clone, "clone node", undoData)

undoData = u.beforeMoveNode(one_clone)
one_clone.moveToFirstChildOf(three)
u.afterMoveNode(one_clone, "move node to top", undoData)

# Maybe the next step is to set a breakpoint in the "invalid position"
# and trace it from there.
c.executeMinibufferCommand('undo')
c.executeMinibufferCommand('redo')







On Wed, Aug 21, 2019 at 8:15 AM vitalije  wrote:

> In the first case after `if 1:`
> you have called two times child.copy().moveToNext().moveToNext(), while in
> the else case you have called it only once.
> I have tried with one call in both cases and it works without error.
> 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/fced3afd-898a-493c-8b31-c3e5dbff7adb%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/CAO5X8Cw40djUZCsRqc5xz0ZfOkqhpG2Fa6z2Q3i7bJVre2JTAw%40mail.gmail.com.

Invalid position error on redo position move

[Brian Theado]

In the code I've been writing, there is one particular case which gives an
"invalid position" error when I redo it. I've written some simplified code
which replicates the scenario (even removing the grouped undo allows the
issue to duplicate).

The code performs 3 individually undoable operations: insert, clone, then
move. The error comes after undoing the move and then redoing that same
move.

Just sharing in case someone sees something obviously wrong. Otherwise I'll
be digging deeper sometime this week.

Procedure:

   1. Copy the below xml
   2. open a new leo outline
   3. Ctrl-shift-v to paste the nodes
   4. Ctrl-b to execute

Error looks like this:

setCurrentPosition Invalid position: 'newHeadline', root: 'NewHeadline'
select,selectHelper,select_new_node,set_body_text_after_select
setCurrentPosition Invalid position: 'newHeadline', root: 'NewHeadline'
new_cmd_wrapper,redo,redoMove,selectPosition



http://leoeditor.com/namespaces/leo-python-editor/1.1;
>


redo bug (use ctrl-b)
one
two
three




@language python

# Code written to assume this descendent structure
# one
# two
#   three
parent = p; u = c.undoer

# Will the issue still reproduce without the insert?
if 1:
undoData = u.beforeInsertNode(parent)
child =parent.insertAsNthChild(0)
u.afterInsertNode(child, "insert as first child", undoData)
sibling =  child.copy().moveToNext().moveToNext()
else:
# Nope. The issue doesn't duplicate with this
child = parent.copy().moveToFirstChild()
sibling = child.copy().moveToNext()

undoData = u.beforeCloneNode(child)
clone = child.clone()
u.afterCloneNode(clone, "clone node", undoData)

undoData = u.beforeMoveNode(clone)
clone.moveToFirstChildOf(sibling)
u.afterMoveNode(clone, "move node to top", undoData)

# Maybe the next step is to set a breakpoint in the "invalid position"
# and trace it from there.
c.executeMinibufferCommand('undo')
c.executeMinibufferCommand('redo')






-- 
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/CAO5X8Cx15dS8oktjUBQ%3DTk8rRTqxTYPR7jhOfcVxa%3DhZnL_4CA%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

Sure, I'll do that or figure out the segfault issue sometime this week.

On Tue, Aug 20, 2019 at 7:26 AM Edward K. Ream  wrote:

> Unfortunately, I'm not able to run unit tests without getting a segfault.
>>
> Alright.  Create a new branch, and I'll run the unit tests there.
>

-- 
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/CAO5X8CwnBvyHgojLp4%3DKg1d_YofUAZU5fNTjGn15j-hxEr7rbw%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

Unfortunately, I'm not able to run unit tests without getting a segfault.
It appears to be related to loading the readline library similar to what I
reported last year:
https://groups.google.com/d/msg/leo-editor/ghiIN7irzY0/2wreFgcYDQAJ. Though
now I'm running Ubuntu 18.04. Something in the unit test code causes pdb to
be loaded which loads readline and causes the crash.

I faced the same issue when trying to set breakpoints in code...invoking
pdb crashed. I solved that by launching leo with 'python -m pdb'. Somehow
when doing it that way there was no crash. However, the same workaround
didn't work for running the unit tests. I have some ideas on tracking it
down further, but I haven't gotten to it yet.

On Tue, Aug 20, 2019 at 6:15 AM Edward K. Ream  wrote:

>
>
> On Mon, Aug 19, 2019 at 7:04 PM Brian Theado 
> wrote:
>
>> I found a core function which uses undo groups and used this code to call
>> it:
>>
>> c.createNodeHierarchy(['a', 'b', 'c'], parent=p)
>> c.redraw(p)
>>
>> Redoing this operation gives the same error as the test code and the
>> bead+1 fixes it also. I think this bug is affecting all grouped redo.
>>
>
> Thanks for this work.  Does the proposed change pass all unit tests?
>
> 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/CAMF8tS20sv7uEzmpFH8Sf65h5JRDF_kX_rvDyggbqK8%2BhJKi5g%40mail.gmail.com
> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS20sv7uEzmpFH8Sf65h5JRDF_kX_rvDyggbqK8%2BhJKi5g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAO5X8Cz%3DQBbjBFEq9EjdRFoCkXq0%3DY6vQTYXPz7GXm7j1xjDaA%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

I found a core function which uses undo groups and used this code to call
it:

c.createNodeHierarchy(['a', 'b', 'c'], parent=p)
c.redraw(p)

Redoing this operation gives the same error as the test code and the bead+1
fixes it also. I think this bug is affecting all grouped redo.


On Mon, Aug 19, 2019 at 7:54 PM Brian Theado  wrote:

> I think the issue is in u.redoGroup (leo/core/LeoPyRef.leo#Code-->Core
> classes-->@file leoUndo.py-->class Undoer-->u.redo helpers-->u.redoGroup)
>
> The line:
> bunch = u.beads[*u.bead*]; count = 0
>
> Should be:
> bunch = u.beads[*u.bead+1*]; count = 0
>
> That line is in both u.undoGroup and u.redoGroup. For undoGroup u.bead is
> valid, but for redo it should be operating with u.bead+1.
>
> Brian
>
>
> On Sun, Aug 18, 2019 at 5:18 PM Brian Theado 
> wrote:
>
>> Hmm, it didn't work for me. Using your code and following the same steps
>> as my original email, I get the same error message.
>>
>> After that if I start from step #4 (the ctrl-b step) again, then the undo
>> and the redo work. But then if I start again at step #4, I get the original
>> error message again.
>>
>> Could you confirm it is working for you even starting from scratch?
>>
>> On Sun, Aug 18, 2019 at 9:32 AM Edward K. Ream 
>> wrote:
>>
>>>
>>>
>>> On Sun, Aug 18, 2019 at 8:28 AM Edward K. Ream 
>>> wrote:
>>>
>>>>
>>>> On Sun, Aug 18, 2019 at 8:24 AM Edward K. Ream 
>>>> wrote:
>>>>
>>>> At least one problem is that p changes after:
>>>>
>>>> child = parent.insertAsNthChild(0)
>>>>
>>>
>>> This works:
>>>
>>> groupType = 'insert child twice'
>>> undoType = 'insert first child twice'; u = c.undoer
>>> # Start group.
>>> parent = p.parent()
>>> u.beforeChangeGroup(parent, groupType)
>>> # 1
>>> undoData = u.beforeInsertNode(parent)
>>> child = parent.insertAsNthChild(0)
>>> u.afterInsertNode(child, undoType, undoData)
>>> # 2
>>> undoData = u.beforeInsertNode(parent)
>>> child = parent.insertAsNthChild(0)
>>> u.afterInsertNode(child, undoType, undoData)
>>> # End group.
>>> u.afterChangeGroup(parent, groupType)
>>> c.redraw(child)
>>>
>>> This fails if p.parent() does not exist, but that's another matter.
>>>
>>> Also note the two different undo types.  That's probably not necessary,
>>> but it's better style.
>>>
>>> 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/CAMF8tS1RaaS8qumebOtNLaT%3DLVpx_kajWcTjjQUGfnV8LuW3Ng%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS1RaaS8qumebOtNLaT%3DLVpx_kajWcTjjQUGfnV8LuW3Ng%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/CAO5X8CzMuHdJKKhmH1aZ19AGAx3GoVXpNEty_UBcjs5k2A1BPw%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

I think the issue is in u.redoGroup (leo/core/LeoPyRef.leo#Code-->Core
classes-->@file leoUndo.py-->class Undoer-->u.redo helpers-->u.redoGroup)

The line:
bunch = u.beads[*u.bead*]; count = 0

Should be:
bunch = u.beads[*u.bead+1*]; count = 0

That line is in both u.undoGroup and u.redoGroup. For undoGroup u.bead is
valid, but for redo it should be operating with u.bead+1.

Brian


On Sun, Aug 18, 2019 at 5:18 PM Brian Theado  wrote:

> Hmm, it didn't work for me. Using your code and following the same steps
> as my original email, I get the same error message.
>
> After that if I start from step #4 (the ctrl-b step) again, then the undo
> and the redo work. But then if I start again at step #4, I get the original
> error message again.
>
> Could you confirm it is working for you even starting from scratch?
>
> On Sun, Aug 18, 2019 at 9:32 AM Edward K. Ream 
> wrote:
>
>>
>>
>> On Sun, Aug 18, 2019 at 8:28 AM Edward K. Ream 
>> wrote:
>>
>>>
>>> On Sun, Aug 18, 2019 at 8:24 AM Edward K. Ream 
>>> wrote:
>>>
>>> At least one problem is that p changes after:
>>>
>>> child = parent.insertAsNthChild(0)
>>>
>>
>> This works:
>>
>> groupType = 'insert child twice'
>> undoType = 'insert first child twice'; u = c.undoer
>> # Start group.
>> parent = p.parent()
>> u.beforeChangeGroup(parent, groupType)
>> # 1
>> undoData = u.beforeInsertNode(parent)
>> child = parent.insertAsNthChild(0)
>> u.afterInsertNode(child, undoType, undoData)
>> # 2
>> undoData = u.beforeInsertNode(parent)
>> child = parent.insertAsNthChild(0)
>> u.afterInsertNode(child, undoType, undoData)
>> # End group.
>> u.afterChangeGroup(parent, groupType)
>> c.redraw(child)
>>
>> This fails if p.parent() does not exist, but that's another matter.
>>
>> Also note the two different undo types.  That's probably not necessary,
>> but it's better style.
>>
>> 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/CAMF8tS1RaaS8qumebOtNLaT%3DLVpx_kajWcTjjQUGfnV8LuW3Ng%40mail.gmail.com
>> <https://groups.google.com/d/msgid/leo-editor/CAMF8tS1RaaS8qumebOtNLaT%3DLVpx_kajWcTjjQUGfnV8LuW3Ng%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CAO5X8Cw75Pu9UjwwCwRnrzzC8QhNQ5mgpy-Bg8Jm9x15bvuSFA%40mail.gmail.com.

Re: Having trouble writing a simple grouped undo/redo

[Brian Theado]

Hmm, it didn't work for me. Using your code and following the same steps as
my original email, I get the same error message.

After that if I start from step #4 (the ctrl-b step) again, then the undo
and the redo work. But then if I start again at step #4, I get the original
error message again.

Could you confirm it is working for you even starting from scratch?

On Sun, Aug 18, 2019 at 9:32 AM Edward K. Ream  wrote:

>
>
> On Sun, Aug 18, 2019 at 8:28 AM Edward K. Ream 
> wrote:
>
>>
>> On Sun, Aug 18, 2019 at 8:24 AM Edward K. Ream 
>> wrote:
>>
>> At least one problem is that p changes after:
>>
>> child = parent.insertAsNthChild(0)
>>
>
> This works:
>
> groupType = 'insert child twice'
> undoType = 'insert first child twice'; u = c.undoer
> # Start group.
> parent = p.parent()
> u.beforeChangeGroup(parent, groupType)
> # 1
> undoData = u.beforeInsertNode(parent)
> child = parent.insertAsNthChild(0)
> u.afterInsertNode(child, undoType, undoData)
> # 2
> undoData = u.beforeInsertNode(parent)
> child = parent.insertAsNthChild(0)
> u.afterInsertNode(child, undoType, undoData)
> # End group.
> u.afterChangeGroup(parent, groupType)
> c.redraw(child)
>
> This fails if p.parent() does not exist, but that's another matter.
>
> Also note the two different undo types.  That's probably not necessary,
> but it's better style.
>
> 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/CAMF8tS1RaaS8qumebOtNLaT%3DLVpx_kajWcTjjQUGfnV8LuW3Ng%40mail.gmail.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/CAO5X8Cwe4q%2B%2BVOoKcWVqPkKBYqF1oHCfEJ1mCnLOTJ-4nn5urg%40mail.gmail.com.