History is broken for non-top level

[AHSauge]

See the attached example where I've tried to get history to work for all three levels in the example provided in the repository.

My interaction is as follows:

TopLevel second say asd 
You called a command in SecondLevel with 'asd'. It has access to top_level_attr: 123456789
TopLevel second
TopLevel >> 2ndLevel third say qwe 
You called a command in ThirdLevel with 'qwe'. It has access to top_level_attr: 123456789 and second_level_attr: 987654321

We can see that from the top level I have executed 'second say asd' and on the second level I have excuted 'third say qwe'

When restarting the script, I can correctly press arrow up to find both 'second' and 'second say asd'. However, if I go into the second level I only get gibberish like '(X^D', 'q^FX^G' and 'q^B)�q^C}q^D(X '

Here is a zip file of the script and the history file after the first execution
example.zip

[tleonhardt]

We dramatically changed how history works for newer versions of cmd2. I suspect we need to modify the setup.py to put in a maximum version of cmd2 that this plugin works with. Tentatively my guess would be that if we stick with 0.9.6 <= cmd2 <= 0.9.10 then I think this plugin might work OK, but we would need to verify.

To be honest, this plugin isn't very well maintained or a priority for the core cmd2 developers since we believe we now have a better way of achieving similar capabilities by allowing developers to programmatically disable and enable commands.

See the section in the docs on Disabling Comamnds and the help_categories.py example for more info.

[AHSauge]

I see. Thank you for the reply.

I had a look at disable and enable commands, and it doesn't fit my use case at all I'm afraid. I mean, I could use it, but it feels like a giant hack. It's for some internal test tooling at work. Currently we have an application with about 1100 commands spread across 50 modules. The modules are found on the top level, and the commands are the second level. Due to how this tooling works, and the desired use of it, it's not possible to run these modules separately. You really want to start up the application with all modules for all available systems loaded, and then switch between them depending on what you want to test/verify. I'm fully aware that this is quite outside of what cmd2 is meant for, but so far it works quite well.

I already saw that there wasn't much activity in terms of cmd2-submenu, so I was already prepared to have to dive into this myself to fix this. Unfortunately, this is more of a "nice to have" feature for my context, so I don't know when I'll get around to looking at it.

[tleonhardt]

99% of developers using cmd2 use argparse subcommands and associated cmd2 decorators for dealing with that sort of thing, possibly with a plugin architecture.

@kmvanbrunt or @anselor Can either of you comment further?

[kmvanbrunt]

@AHSauge The submenu module has never been stable. It's poorly designed and that's why we moved it out of the main code.

Have you considered using argparse subcommands as a solution? Each of your 50 modules would be a top level command (parser) and all module-specific commands would be subcommands (subparsers) of them.

[anselor]

You can also build 2 levels of argparse parsers. The upper layer can load your plugin modules and auto-complete them as if they're a sub-command. Then consume all remaining arguments and then pass them down to the next layer's argparser.