feat(!): Major rework to blessed

[bigpick]

Info

This would somewhat address and/or entirely close:

• Fix for VS Code #108
• input() after picking breaks the typing portion of input #83
• Refactor with blessed #58
• Support for disabled list entries? #29
• Choose color for written text #21
• [REQUEST] add NUMPAD_ENTER for picking #111
• Filter options as you type #48

Changes

1. Changes over to using blessed for the screen writing
   • Adds support for easier colored text
2. Makes un-selectable options (via setting the Option's enable value to False) visually distinct to show un-selectable
   • Will render the value in the selection list as a greyed out value, and won't allow selecting it
3. Adds the ability to filter by typing
   • Any key letter key thats not up/down/exit goes to filter, which is displayed at the top
     • If no values match the current filter, warning message is displayed to remove filter constriction

TODO:

1. Increased flexibility for coloring options?

Can specify a color to an Option() now, as well as specifying the disabled color and pagination tip colors to pick(); in addition, because not using curses, ansi codes can be used anywhere and interpreted appropriately.

2. Ensure closer parity to existing pick library currently
* Biggest gap is the existing screen option; don't know that that would be even possible to do while leveraging blessed? It seems not likely, unless I'm missing something.
* Notably: the example/position.py is the only example that is not working equivalently

I'm convinced that switching to blessed entirely breaks interoperability with curses - this would need to be a discussion, I think? for this reason, I've set it to a major version upgrade - though I fear that this change will disrupt a good group of people who chose this package (bc they already had a curses app and wanted a nice pre-built menuing utility)? I am unsure what percentage of people that use this package absolutely require it to be interoperable with curses, but by going to blessed, I am of the opinion that it removes that option completely.

3. ???

I would appreciate any further input/thoughts as well, thanks!

[bigpick]

demo

1. Multi-pick, showing enforced pick number + selecting/un-selecting
2. Single-pick, with filter
3. Scroll case, with filter including too restrictive filter

[bigpick]

The pagination/scrolling still needs some work; The chunking approach won't always work because if you have a particularly long line(s), they can wrap over and take up more than one line vertically, and that messes up that approach

[aisk]

I'm not sure whether we should switch to blessed or not, but in my opinion, it's not good to add too many features in one PR. Maybe we can split the enhancement parts into other small PRs if possible. If they are coupled with blessed, we can add them later.

I don't know if we can make the backend (curses or blessed) selectable, so the user can specify using curses for existing TUI apps.

[jquast]

Just to chime in that blessed is fully interoperable with existing curses applications, that is part of the intended design, it produces no side effects -- except when using the context managers that describe their intended effects, saving terminal modes and restoring them for context managers that use it.

Only curses.setupterm(), which is a non-op when called multiple times, and curses.tigetnum and curses.tparm are called, both side-effect free. And although blessed is windows-compatible (using jinxed), we're also investigating removing the curses dependency entirely, making us compatible with even more restrained environments (like micropython, etc), It's our only remaining issue after 12 years!

I do agree that blessed can resolve all of the referenced issues. Hope you use it, please enjoy !

[aisk]

@jquast Hi thank you for noticing. The blessed support is already introduced in #157 as an optional backend besides curses.

[aisk]

Closed by #157, Thank you for contributing anyway!