Closed RinHizakura closed 1 year ago
Thank you for your PR. We recently merged #173 which introduced some large scale changes to the code, so there are a lot of conflicts now. Sorry for that.
I just fix the conflicts. Please take a look again if you may like to accept this change!
Thank you.
@sharifhsn Maybe we should merge this first? What do you think?
Yes, that's a good idea. I can modify my clap4
PR so that it updates this as well. Alternatively, clap
could be updated and this PR would change to use it.
@RinHizakura This looks good from a first review. Can we please add an (integration) test for this new feature?
Alternatively,
clap
could be updated and this PR would change to use it.
Okay. I just merged the clap v4 branch. If you're interested, maybe you could support here with updating the CLI code for the group_bytes
option.
Hi, some of the integration tests are provided now. Please check whether we'll need more tests on the other special patterns which I wasn't come up to.
This PR is going to support different sizes of data which can almost fit the requirement of #104, without the endian option. Since there's some "magic" number (e.g. the number "25") related to this originally, I also try my best to replace those with a specific abstraction so we can simpler add more features accordingly. To be simple, also note that I make the panel size change dynamically according to the bytes in the group, so the string
No content to print
has to be modified toNo content
to fit the panel when-g 16
. It's fine if you have better ideas about this change.If you think this PR makes sense, I will also add more test cases to robust this feature, thanks!