Recoverpy

:tada::tada::tada: **A whole new version of RecoverPy is here!** :tada::tada::tada:

The main change and main reason for this new major version is a **TUI framework shift to `textual`.**

UI has been entirely rewritten with `textual`, UI workflow has been rethinked and modified.

Under the hood, I also tried to optimize previous search logic, RecoverPy should be more efficient overall.

I dropped support for Python 3.6, mainly because its EOL has been reached a year ago. Python 3.7 is not supported starting from this version too, it's a requirement from `textual` and should not be an issue as its EOL is planned to be in 5 months.

**Now, RecoverPy requires Python > `3.8`.**

Other than that, you'll probably appreciate the new UX, technically RecoverPy should work just as before.

Any Issue, bug report, you name it, will be greatly appreciated. This obviously goes too for PRs, especially regarding `textual` if you have better UI/UX ideas.

_If you do encounter any bug with this version, again a GitHub issue would be welcome, but if you do need RecoverPy to be working now you can try installing previous version, `1.5.2`._

What's new ?

- Some minor UI fixes.
- Fix unrelated results for queries containing special characters.

Known Issues

None :+1:

Future plans

- Explore other TUI Python libraries to offer a better and more reliable terminal UX.
- MacOS compatibility will go dormant for now as there seems to be little to none demand for it.

What's new ?

- Multi-line search has been fixed

Known Issues

None :+1:

Future plans

- Explore MacOS compatibility. See 8.

What's new ?

- The project structure has been refactored.
- Test coverage has been greatly improved, currently 90%.

- Binary file search has been improved, for you madlads that might do it.
Before, and because of how grep is used, a result was a line containing your searched string. The thing is, grep is expecting a newline character in order to consider this line over, which might not at all be present in a binary file.
That caused displayed results to be quite random for binary files, they might have been way too long and the given result block number, being calculated from grep output, was off by a few blocks.
Now this offset is taken into account, you will always see your searched string in the results and the associated partition block will always be precisely the one with your string in it.

- In order to fix old issues related to `py_cui`, RecoverPy now depends on its own `py_cui` fork. Depending on how this upstream library is maintained in the future, it might or might not be permanent.

- Multiple UI related bugs were fixed, let's call it quality of life.


Known Issues

None :+1:

Future plans

- Explore MacOS compatibility. See 8.

What's new ?

- The main purpose of this release is to bump `py_cui` to version 0.1.4 in order to fix various bugs.

Known Issues

- 14 - To be fixed in `py_cui` 0.1.5

Future plans

- Explore MacOS compatibility. See 8.
- Implement any relevant new `py_cui` features.

Future plans

- Replace `os.path` by `pathlib`.
- Implement any relevant new `py_cui` features.