sharkdp
Print using custom width
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
hexylcalculate 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. :)
Sounds good, but would probably require a small rewrite of the layout rendering "logic".
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.
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.
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)