cmd2 3.0.0 Discussion

[kmvanbrunt]

Now that cmd2 2.5.0 is out, I'd like to start thinking about cmd2 3.0.0. So here are a few features I'd like to see based on feedback we've received over the years.

• Full rich and rich-argparse integration.

  • I wrote the table and related formatting code in early 2020 to solve a problem that all existing table creators at the time had. None of them preserved text styles across multiple lines of a table cell. That was also right around the time rich was developing their table functionality so I wasn't aware of their library. In the years since, rich has become the de facto library for formatting text in the terminal and it's widely used and well supported. So I think it's safe at this point to offload all of our text formatting to rich. This approach was also discussed in #1251 .

  • I have been testing our stuff with rich-argparse and I'm finding the switch very easy.

• Make async alerts and prompt changes event driven.

  • Currently developers must obtain self.terminal_lock to asynchronously print an alert. In cmd2 3.0 they will call a function like add_alert() which adds to a queue and cmd2 will handle printing alerts when the prompt is on screen. Async prompt updates will provide a similar method.

• Consider moving some built-in commands to CommandSets or mixin classes.

  • What commands are best suited for this?

• Remove macros.

  • They were a neat idea at the time, but as 1350 points out, the lack of custom tab completion makes them difficult and confusing to use. Removing macros also eliminates the need for self._input_line_to_statement(). We could just call self._complete_statement() directly.

• 1334

  • Moving the ext_test plugin might help here as well. It currently has its own build system and is required to run our unit tests. Can it become a part of the main cmd2 code or at least not be needed to run our unit tests?

[tleonhardt]

I think replacing most of cmd2's custom text formatting code with a combination of rich and rich-argparse is a fantastic idea. It will reduce the amount of custom code that we need to maintain for cmd2 and allow us to bring in some additional functionality while presenting our users with the now idiomatic features available within rich.

I'm intrigued by the idea of making async alerts and prompt changes event driven, but I'd want to understand more about the architecture for how this would work and how it may interact or interfere with other event loops. For this sort of thing, I think we should consider integrating with Textual as this provides a path to true terminal-based UIs.

[tleonhardt]

@anselor @kotfu Do either of you have any thoughts or opinions on any of the above?

[anselor]

I think I understand what @kmvanbrunt is getting at about alerts. As I recall, right now it's the caller's responsibility to figure out what state the prompt is in and either immediately print an alert or come up with a mechanism to queue up the alert for later display. Rearchitecting so that we consume the alert and determine in cmd2 when/how to display the alert. In the most basic case, if the terminal is busy executing a command, then the alert gets queued. If the terminal is at the prompt then we do our prompt redraw thing. This opens the door for more advanced alerting methods that could take advantage of something like textual to have a dedicated GUI-like way of displaying alerts.

I agree with moving the plugins back into cmd2 proper and integrate it with unit tests. It would make sense to expand our unit tests to handle cases with different combinations of commandsets / plugins loaded. The build system update will go a long way towards helping that.

Definitely agree with trying to move more commands into pre-canned CommandSets.

Definitely agree on rich. At this point it's quite mature.