Minibuffer command list does not show user-added commands

[tbpassin]

Update: See Leo issue 2093.

I have some custom commands that are not bound to keys or buttons. They do not show up in leointeg's minibuffer command list. How can I run them without binding them to to a button?

I know that the Bridge code includes lists of commands that are allowed or disallowed. I can see the sense of that. But it leaves my own custom commands out in the cold.

[edreamleo]

@tbpassin Thanks for creating this issue. I'm not sure the good/bad lists are the culprit, but that's just speculation on my part.

[boltex]

@edreamleo

• The good list only serves as a check that would output a print log about a good command being also in the bad list.
• The bad list is the only one of those 2 lists of string that discriminates.

the method in leoserver is called ​get_all_leo_commands, it's getting its base list from c.commandsDict.

I'm gonna check why / how at-commands dont end up there. i'm new to those so go ahead if you have thoughts about that ! :)

[boltex]

I'll assign it to you - although it should be done in Leo-editor's leoserver.py instead of leointeg ( i might be wrong - feel free to comment or whatever you feel appropriate)

[tbpassin]

It is the user-defined command that aren't showing up. These are ones whose headline starts with @command. I know that commands in specific outline aren't getting listed. I'm not sure about commands defined in myLeoSettings.leo, but my guess is that they aren't either.

When leointeg sees a headline beginning with @button, it creates a button bound to that command. So that part works as expected. When such a button gets pressed, it can fire a user-defined command, and that works.

If @commands get added to the Leo command editbox, it would need to be on a per-outline basis. I don't know if the current leointeg design can do that or not.

[edreamleo]

@boltex I'll do this next. BTW, unless there are serious doubts about a commit, I recommend merging dev into master almost immediately. That way we can all just pull master and be sure that we are getting the latest code. In other words, I think we should all be testing new code asap. Worst case: we check out a previous rev in master.

[edreamleo]

@tbpassin Should be straightforward to fix.

[edreamleo]

Background: Within Leo itself, commands created by @button and @command show up in Leo's minibuffer in two ways:

<Alt-x>@c<tab> shows all commands defined by @command nodes, both local and global. All such command names start with the prefix @command-.

<Alt-x>@b<tab> shows all commands defined by @button nodes, both local and global. All such command names start with the prefix @button-.

The minibuffer will also show the same commands without the @button- or @command- prefixes. For example, I have defined (somewhere, it doesn't matter where) @command-join-node-above. This works as expected:
<Alt-x>join<tab>

The code in Leo to make all this "just work" is probably pretty hairy. Happily, only c.commandsDict matters.

[edreamleo]

As a prototype, the following Leonine script prints all unique command names, that is, c.commandsDict keys, with duplicate command-names deleted. The script also deletes Leo's vim-mode-related commands, that is, commands starting with ':'.

def unique_commands():
    return (key for key in c.commandsDict
        if not key.startswith(('@button-', '@command-', ':')))
    
g.printObj(sorted(unique_commands()))

[edreamleo]

@boltex I agree that the new code should be in leoserver.py.

[edreamleo]

A trace in server.get_all_leo_commands shows that c.commandsDict contains no entries starting with @command. This looks like a bug in either leoserver.py or leoBridge.py. I'm on it.

[edreamleo]

Update: There are several bugs, all in leoserver.py. server.__init__ creates a dummy commander as follows:

self.dummy_c = g.app.newCommander(fileName=None)

Alas, g.app.newCommander never reads settings, so the dummy commander has no chance of knowing about @command or @button nodes. Instead, server.get_all_leo_commands must use a real commander.

Happily, this bug is easy to fix:

1. In server.get_all_leo_commands, use self.c, not self.dummy_c.
2. In server._bad_commands, disallow only vim commands (commands starting with ':').'
   We do want to allow the user to type <Alt-x>@command<tag> !

Now another bug appears:

server:  ServerError: _do_leo_command: Leo command not found: 'registerAllCommandsCallback'...
server:  {'id': 24, 'action': 'registerAllCommandsCallback', 'param': (doesn't matter)

This is almost expected :-) In mod_scripting.py, in sc.registerAllCommands, the code registers the command name without the @button or @command and calls k.registerCommand with the name and the callback, which naturally leoserver.py can't find. We'll get there.

[edreamleo]

I am going to close this. However, see #180.