Print using custom width

[ErichDonGubler]

This is excellent, and the default width of 16 is great! It'd be really nice if we could print according to custom alignments, though -- this is a fairly standard feature in most hex editors, and I can't imagine it being egregiously complex to add this.

Another couple of ideas:

• Getting the max width based on a provided terminal width would be nice -- this would let me simply plug in a width and let hexyl calculate the space overhead of borders for me.
• An auto-width flag (which is like the above for the current terminal width) to be used would also be handy -- it would have some overlap with the above, but there could be reasons for setting

Prototypical suggestion for options:

# Ideas for a fixed column width:
-c --columns        Sets the number of hex data columns to be displayed.
                    Cannot be used with other width-setting options.
-w --width

# Ideas for terminal auto-width:
-a --auto-width     Sets the number of hex data columns to be adjusted according
                    to the detected terminal width. Conceptually, this could be an
                    alias of `-t $terminal_width`.
                    Cannot be used with other width-setting options.

# Ideas for fixed terminal width:
-t --terminal-width Sets the number of terminal columns to be displayed.
                    Since the terminal width may not be an evenly divisible by the 
                    width per hex data column, this will use the greatest number of 
                    hex data columns that can fit in the requested width but still
                    leave some space to the right.
                    Cannot be used with other width-setting options.

I'm more than happy to push on this, if effort is a concern. :)

[sharkdp]

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

[ErichDonGubler]

Updated option proposals to actually have something. :)

[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]

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)