"multiple vnodes with (same) gnx" errors when using reload-settings

[xgid]

Hi,

I was trying to use the new reload-settings command to reload some abbreviations I've just added to myLeoSettings.leo, but this error message was shown at the Log Pane when invoking reload-settings:

multiple vnodes with gnx: 'xgid.20170226035713.20'
new gnx: xgid.20170226035713.20 <VNode e5709d0 @outline-data tree-abbreviations>
new gnx: xgid.20170226035713.20 <VNode 11bebbf0 @outline-data tree-abbreviations>
multiple vnodes with gnx: 'xgid.20170226035713.21'
new gnx: xgid.20170226035713.21 <VNode 11bebc10 per-commander-plugin;;>
new gnx: xgid.20170226035713.21 <VNode e570ef0 per-commander-plugin;;>
multiple vnodes with gnx: 'xgid.20170226035713.22'
new gnx: xgid.20170226035713.22 <VNode 11bebe90 @@file pluginname.py>
new gnx: xgid.20170226035713.22 <VNode e570e70 @@file pluginname.py>
multiple vnodes with gnx: 'xgid.20170226035713.23'
new gnx: xgid.20170226035713.23 <VNode e5706d0 << docstring >>>
new gnx: xgid.20170226035713.23 <VNode 11bebdf0 << docstring >>>
multiple vnodes with gnx: 'xgid.20170226035713.24'
new gnx: xgid.20170226035713.24 <VNode e570c50 << version history >>>
new gnx: xgid.20170226035713.24 <VNode 11bebcf0 << version history >>>
multiple vnodes with gnx: 'xgid.20170226035713.25'
new gnx: xgid.20170226035713.25 <VNode e570dd0 << imports >>>
new gnx: xgid.20170226035713.25 <VNode 11bebcd0 << imports >>>
multiple vnodes with gnx: 'xgid.20170226035713.26'
new gnx: xgid.20170226035713.26 <VNode 11bebcb0 init>
new gnx: xgid.20170226035713.26 <VNode e5708d0 init>
multiple vnodes with gnx: 'xgid.20170226035713.27'
new gnx: xgid.20170226035713.27 <VNode e570550 onCreate>
new gnx: xgid.20170226035713.27 <VNode 11bebc50 onCreate>
multiple vnodes with gnx: 'xgid.20170226035713.28'
new gnx: xgid.20170226035713.28 <VNode 11bebfb0 class pluginController>
new gnx: xgid.20170226035713.28 <VNode e570f50 class pluginController>
multiple vnodes with gnx: 'xgid.20170226035713.29'
new gnx: xgid.20170226035713.29 <VNode e570eb0 __init__>
new gnx: xgid.20170226035713.29 <VNode 11bebff0 __init__>
multiple vnodes with gnx: 'xgid.20170226035713.30'
new gnx: xgid.20170226035713.30 <VNode e5701d0 demo;;>
new gnx: xgid.20170226035713.30 <VNode 11bebf70 demo;;>
multiple vnodes with gnx: 'xgid.20170226035713.31'
new gnx: xgid.20170226035713.31 <VNode 11bebe10 @@button MyDemo @key=Ctrl-9>
new gnx: xgid.20170226035713.31 <VNode e5701f0 @@button MyDemo @key=Ctrl-9>
multiple vnodes with gnx: 'xgid.20170226035713.32'
new gnx: xgid.20170226035713.32 <VNode 11bebd30 << imports >>>
new gnx: xgid.20170226035713.32 <VNode e570450 << imports >>>
multiple vnodes with gnx: 'xgid.20170226035713.33'
new gnx: xgid.20170226035713.33 <VNode 11bebd10 script_string>
new gnx: xgid.20170226035713.33 <VNode e5705d0 script_string>
multiple vnodes with gnx: 'xgid.20170226035713.34'
new gnx: xgid.20170226035713.34 <VNode e570510 class myDemo>
new gnx: xgid.20170226035713.34 <VNode 11bf4030 class myDemo>
multiple vnodes with gnx: 'xgid.20170226035713.35'
new gnx: xgid.20170226035713.35 <VNode 11bf4110 wrappers>
new gnx: xgid.20170226035713.35 <VNode e570b50 wrappers>
check-outline ERROR! myLeoSettings.leo 72 nodes, 32 gnx errors, 0 structure errors

What I did first was to copy the whole node leoSettings.leo#@settings-->Abbreviations to myLeoSettings.leo, remove from it the @data global-abbreviations child node and add some custom abbreviations to the body of my @data abbreviations node. Then invoked reload-settings while having myLeoSettings.leo tab focused (and some other tabs opened as well, one of them corresponding to the leoSettings.leo file).

I'm not sure that the error has to do with the reload-settings command, so please change the issue title accordingly.

Version info:
Leo 5.4, build 20170225074748, Sat Feb 25 07:47:48 CST 2017
Git repo info: branch = master, commit = a17f1d3
Python 3.5.2, PyQt version 5.6.0
Windows 10 AMD64 (build 10.0.14393) SP0

[edreamleo]

Fixed at e890cd0. The checkin log incorrectly states that the checkin fixes #340.

[xgid]

Uau, that's really Getting Things Done! Resolution confirmed on my side with:

Leo 5.4, build 20170227081518, Mon Feb 27 08:15:18 CST 2017
Git repo info: branch = master, commit = a9b8ce5c182e
Python 3.5.2, PyQt version 5.6.0
Windows 10 AMD64 (build 10.0.14393) SP0

I've seen you even corrected a bug I had also detected when using the "demo;;" tree-abbreviation... but was waiting to have more time to reproduce it and master the tree abbreviations before reporting. Great!

[edreamleo]

On Mon, Feb 27, 2017 at 8:41 AM, XGiD ***@***.***> wrote: Uau, that's really *Getting Things Done*! Resolution confirmed on my side with: Leo 5.4, build 20170227081518, Mon Feb 27 08:15:18 CST 2017 Git repo info: branch = master, commit = a9b8ce5 Python 3.5.2, PyQt version 5.6.0 Windows 10 AMD64 (build 10.0.14393) SP0

​Thanks. These confirmations are important.​

I've seen you even corrected a bug I had also detected when using the "demo;;" tree-abbreviation... but was waiting to have more time to reproduce it and master the tree abbreviations before reporting. Great!

​Glad to hear it. Not redrawing the tree properly was a bad bug. Leo acted strangely until the next redraw. Edward

[xgid]

By the way, tree abbreviations are IMPRESSIVE, to say the least!

I'm trying to master them in order to see their possibilities, are they explained in depth somewhere? I could not find too much at Leo's Documentation...

[edreamleo]

On Mon, Feb 27, 2017 at 10:41 AM, XGiD ***@***.***> wrote: By the way, tree abbreviations are *IMPRESSIVE*, to say the least! I'm trying to master them in order to see their possibilities, are they explained in depth somewhere? I could not find too much at Leo's Documentation <http://leoeditor.com/search.html?q=abbreviation>...

​When I have questions about settings, I look first in leoSettings.leo.​ There is a little explanation at: unl://C:\leo.repo\leo-editor\leo\config\leoSettings.leo#@settings:3-->Abbreviations:0-->@outline-data%20tree-abbreviations:5 ​But not very much. There are more formal docs here <http://leoeditor.com/tutorial-pim.html#using-abbreviations-and-templates>, but it doesn't cover tree abbreviations. I've just made a note to expand both places. Please ask any questions you like. Our discussion will be pre-writing for the docs. Edward

[xgid]

Thanks for offering your help. I've read all the explanations you've pointed me to and at this point I've been left with these questions (which for some of them I think I already know the answer for, but I'd better get your confirmation):

• Is there any way to insert placeholders for fields to be filled in (like <|a-field-name|>) in tree abbreviations like there's for simple abbreviations (what you call templates)? I think the answer is NO.
• Can I include abbreviation scripts in the headlines and/or body of any of the nodes of a tree abbreviation and they will be evaluated as expected? I've already verified that I can and the basic examples seem to work fine, but I do not understand what can be evaluated and what not. So...
• What kind of expressions can I set as abbreviation scripts? Why is the x= part in expressions like {|{x=str('@')}|} necessary?
• Is there a reason why the "demo;;" example defines a node starting with @@button instead of just @button? I understand that this is the only way to avoid Leo from interpreting the @button as a definition of a button to add right there, in the leoSettings.leo file itself.
• If my guess above is right: is there any way to make the resulting tree (after the tree abbreviation expansion) to have a heading with an @button instead of an @@button? I've already tried with various hacks like this one:

{|{x=str('@')}|}button MyDemo @key=Ctrl-9

without success.

I think I'm done for now.

[edreamleo]

On Wed, Mar 1, 2017 at 11:54 PM, XGiD ***@***.***> wrote: Is there any way to insert placeholders for fields to be filled in (like <|a-field-name|>) in tree abbreviations like there's for simple abbreviations (what you call templates)? I think the answer is NO.

​Why do you say no? The ​ ​per-commander-plugin;; abbreviation in leoSettings.leo contains, for example: ​''' <|docstring|> '''

- Can I include *abbreviation scripts* in the headlines and/or body of any of the nodes of a tree abbreviation and they will be evaluated as expected? ​Yes. Why wouldn't they? Have you run a few tests? - What kind of expressions can I set as *abbreviation scripts*? Why is the x= part in expressions like {|{x=str('@')}|} necessary? ​Scripts execute in an environment, and the assignment alters that

environment. The symbol "x" is used in various ways by the background machinery. Yes, it's a bit wonky, but if you follow the pattern things will work.​ The @DaTa abbreviations-subst-env actually determines the environment. As you will see, the children of this node define various functions. If you *really* want to understand the details, read that code.

- Is there a reason why the "demo;;" example defines a node starting with @@button instead of just @button? - I understand that this is the only way to avoid Leo from interpreting the @button as a definition of a button to add right there, in the leoSettings.leo file itself. ​Yes.​ - If my guess above is right: is there any way to make the resulting tree (after the tree abbreviation expansion) to have a heading with an @button instead of an @@button? ​Make the change by hand. It shouldn't be too odious ;-)

Edward

[xgid]

I'm sorry it took me so long to answer to your questions.

Why do you say no? The per-commander-plugin;; abbreviation in leoSettings.leo contains, for example: ? ''' <|docstring|> '''

Well, I did not look at that example because I could not even understand the meaning of "per-commander-plugin"... :P

I just tried with a tree-abbreviation of my own like this one:

mdfile;;
	@clean <|filename|>.md
		""" The body here """

That's a tree-abbreviation with one only node with a placeholder in its headline. It did not work. The ",," shortcut did not found any placeholder to jump to.

Thanks to your example, now I see that this only fails for placeholders in the headlines. Placeholders in node bodies do work as expected. Is this a bug?

The @DaTa abbreviations-subst-env actually determines the environment.

OK, as a workaround to the avobe, I've seen I can use the "ask" function. That will suffice.

Of all the functions defined there, I think I understand all but the "insert":

'''Insert the string s in the current widget.'''

I've made some tests and just don't get it. But that's a minor problem.

Thanks alot for your answers and your time!

[edreamleo]

Here's what should happen for any abbreviation, assuming usual default settings and abbreviations that end with ;; (two semicolons)

Type the abbreviation. When you type the second ; Leo will insert the entire abbreviation and will select the first item to be filled in. Type the field and then then type ,, (two commas) to move to the next field. When you have filled in the last field, typing two commas does nothing more (except delete the first comma you typed)

[xgid]

Hi Edward, thanks for your explanation. I had already figured out what was the expected behaviour for abbreviations with placeholders (items to be filled in). What I was trying to say was that they are not working in the expected way you describe when the placeholders are present at the headlines of any of the nodes of the tree-abbreviation.

Let me slightly change the tree abbreviation example of my previous comment to make it more clear:

mdfile;;
	@clean <|filename|>.md
		""" The body here """
		Description: <|summary|>

Now the tree abbreviation has a second placeholder (<|summary|>) inside the body of the only node in the tree. When I insert the abbreviation (by typing "mdfile;;"), the node is correctly created and the cursor is positioned in the <|summary|> placeholder and I can type the field value. But when I press ,, the behaviour is as if I had already filled the last field. In your own words, at this point typing two commas: "does nothing more (except delete the first comma you typed)".

So the placeholder in the headline (<|filename|>) is not recognized as such and is never asked to be filled in.

I hope I've explained it more clearly now. I think this is a bug, but would like a confirmation before opening a new issue (as clearly has nothing to do with this present issue).

Thanks.

[edreamleo]

@xgid Yes, please open a new issue.

[xgid]

Done: #438