Print using custom width about hexyl

[sharkdp]

I'd go with --width N/--columns N first. Once this functionality works reliably (or errors) for all possible N, we can think of adding the auto-width feature which would simply calculate a certain N internally.

It might also be a good idea to look at hexdump and/or xxd. If possible, we should even aim for drop-in compatibility for some options (like I did for -n/--length). Not sure if that should be our prime goal, though.

[sharkdp]

Sounds good, but would probably require a small rewrite of the layout rendering "logic".

[ErichDonGubler]

Updated option proposals to actually have something. :)

[sharkdp]

And yes, I'd be more than happy if you would work on this!

[kilobyte]

It'd probably be good to, by default for -a, observe alignment to 64 bits. Any my use of hd I recently remember that didn't work on a text file dealt with data aligned to either 32 or 64 bits. This also matches hexyl's current display.

[sharkdp]

I think this should still be open, because --columns is not the same as --width (it's similar to --width for a limited number of widths, that are multiples of 8)