Open kmvanbrunt opened 17 hours ago
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.
@anselor @kotfu Do either of you have any thoughts or opinions on any of the above?
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.
Now that
cmd2 2.5.0
is out, I'd like to start thinking aboutcmd2 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
andrich-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 torich
. 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.
self.terminal_lock
to asynchronously print an alert. Incmd2 3.0
they will call a function likeadd_alert()
which adds to a queue andcmd2
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.Remove macros.
self._input_line_to_statement()
. We could just callself._complete_statement()
directly.1334
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 maincmd2
code or at least not be needed to run our unit tests?