What is a proper way to delete a position?

Hello! I'm trying to make a script which would replace a selected node in the outline with the node's "shell copy". The new node should have the same header and body as the original one with all children cloned. After creating the new node the original position should be deleted - and that doe

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

No, I don't think that's what Félix means. Open a .Leo file in say a text editor while it's also open in Leo. In the text editor, make a change to the .leo file and save. Leo doesn't notice the change. I just tried it. After I closed and reopened the .leo file in Leo, the change showed up in

Re: Leo's new unit testing world

On Sun, Dec 6, 2020 at 2:17 PM Brian Theado wrote: > I think the code you have for checking actual vs. expected results is another opportunity for simplification. ... > [for assert s1 == s2 pytest shows]... s1 = self.tempNode.b s2 = self.after_p.b > assert s1 == s2 E

Re: exec python code from myLeoSettings at startup and on reload-settings

On Sun, Dec 6, 2020 at 1:52 PM gar wrote: > Edward, thank you very much for that tip. For at least now dangerous > script execution is enough for my. Developing a plugin is pretty > expensive for my liking. Until I occasionally format my disk c: - I > prefer to play russian roulette for a while.

Re: About the default behavior for externally modifying a .leo file while it's opened in Leo

On Sun, Dec 6, 2020 at 3:21 PM Félix wrote: > Leo does not seem to react to having it's ".leo" file modified while it's opened. I guess you mean, having an opened .leo file modified by another program. Is #1240 what you mean? Leo *does* co

About the default behavior for externally modifying a .leo file while it's opened in Leo

Have'nt change any settigns from default install... Leo does not seem to react to having it's ".leo" file modified while it's opened. Is this the default//desired behavior? Is this new from some recent versions of Leo? Thanks for any insights on this subject! -- Félix -- You received this me

SB: The next phase of sabbatical

I started the sabbatical on October 22. Today marks the end of its (extended!) first phase. I've cleared the decks as followed: - Fixed several important bugs. - Brought two large refactoring projects to reasonable stopping points. They have been marked OnHold

Re: Leo's new unit testing world

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

Re: exec python code from myLeoSettings at startup and on reload-settings

Edward, thank you very much for that tip. For at least now dangerous script execution is enough for my. Developing a plugin is pretty expensive for my liking. Until I occasionally format my disk c: - I prefer to play russian roulette for a while. 2020-12-05 23:28 GMT+03:00, Edward K. Ream : > On M

Re: Leo draws a vim-like box cursor in command mode

On Saturday, December 5, 2020 at 10:05:30 AM UTC-6 Edward K. Ream wrote: Problems remain with both vim mode (@bool vim-mode=True) and vim emulation > (@keys Vim bindings). > > I'll fix these problems first, but that might not be soon... > These problems *have* been fixed. Pull the ekr-vim branch

Merging a PR apparently freezes it

Apparently, after a PR has been merged (effectively closing it), it no longer changes when the branch upon which it is based changes. This seems reasonable. Otherwise the PR would not be a permanent record. I discovered this behavior after merging an earlier version of the ekr-vim branch into

Please test the ekr-vim branch

This branch completes #1757 , which fixes bugs in both vim mode and vim emulation. - vim *emulation*: @keys Vim bindings - vim *mode*: @bool vim-mode Leo 6.3 broke vim emulation and put at least one crasher in vim mode. The bug fixes are th