Add more formatting options

[Aaron-Rumpler]

Adds the following options:

• --hex-inner-separator none Removes the inner separator from the hex display
• --text-inner-separator none Removes the inner separator from the text display
• --outer-border none Removes the outer border (including header, footer and left border, but currently leaves right border in)

TODO:

• Confirm naming of options and associated variables, structs etc.
• Confirm documentation in --help for new options
• Add changes to CHANGELOG.MD
• Add tests for new options
• Check existing tests haven't broken

[sharkdp]

Thank you for your contribution. Could you explain the motivation for this change in a bit more detail? And maybe show a few screenshots how the modified output looks like? Or is there an open ticket that discusses this?

[Aaron-Rumpler]

The primary motivation is that I just find the inner separator on the text column kind of annoying sometimes. I also wanted to be able to output without the top and bottom borders (so that line 1 of the output would correspond to the first line of the actual hex dump), but still keep the separator lines.

[Aaron-Rumpler]

[Aaron-Rumpler]

Only just realised, but combining --hex-inner-separator none, --text-inner-separator none and --outer-border none results in an output very similar to hexdump -C:

[sharkdp]

Thank you very much for the explanation. I'm inclined to accept a change like this, but I would like if we could think about the command-line interface a bit. For example: is there any way we could avoid introducing multiple new options for this?

I also have some questions when looking at the screenshots:

should --hex-inner-separator none also get rid of the longer whitespace separator between the left and right hex block? to be consistent with --text-inner-separator none?

shouldn't this remove the right border as well?

[Aaron-Rumpler]

I would like if we could think about the command-line interface a bit. For example: is there any way we could avoid introducing multiple new options for this?

I agree wrt the command line interface, which is the primary reason this is still a draft PR.

should --hex-inner-separator none also get rid of the longer whitespace separator between the left and right hex block? to be consistent with --text-inner-separator none?

The argument against this would be hexdump -C, which also has the double space gap between the left and right hex block, but no gap on the text.

shouldn't this remove the right border as well?

With the current spacing, I found doing that to look quite unbalanced.

We could do something like this:

There is an issue with not having a right border though (which also affects --border none). With input like this it's hard to tell from the text alone that there's a space there.

Again, hexdump -C has a left and right border on the text, even though it has no other borders.

[sharkdp]

should --hex-inner-separator none also get rid of the longer whitespace separator between the left and right hex block? to be consistent with --text-inner-separator none?

The argument against this would be hexdump -C, which also has the double space gap between the left and right hex block, but no gap on the text.

okay 👍

shouldn't this remove the right border as well?

With the current spacing, I found doing that to look quite unbalanced.

Okay, so maybe we rather use something like --outer-border=none/left/right/both and let the user decide?

There is an issue with not having a right border though (which also affects --border none). With input like this it's hard to tell from the text alone that there's a space there.

Good point. Any suggestions?

Regarding the CLI: can we write down some alternative proposals and comare them? Feel free to also suggest breaking changes (like a reuse of the existing --border option).

[Aaron-Rumpler]

There is an issue with not having a right border though (which also affects --border none). With input like this it's hard to tell from the text alone that there's a space there.

Good point. Any suggestions?

We could print a trailing symbol (like ␄, though there are probably much better options) after the end of the file. There is the case where it ends up on a new line, in which case you just wouldn't show it, as the input ends at the end of a line.

hexdump -C does print a trailing line that includes the total input size, which might be a good idea to offer. In that case, you'd print the ␄ regardless.

Though talking about the ␄ character, there could be an option to display those for control characters (it's not like you could confuse those for that character appearing in the input itself, as it's Unicode).

[Aaron-Rumpler]

shouldn't this remove the right border as well?

With the current spacing, I found doing that to look quite unbalanced.

Okay, so maybe we rather use something like --outer-border=none/left/right/both and let the user decide?

Regarding the CLI: can we write down some alternative proposals and comare them? Feel free to also suggest breaking changes (like a reuse of the existing --border option).

I'm partial to replacing --border with something more like what bat does for --style. Could have left, right, top, bottom, hex-inner, text-inner. none would simply disable all the borders, and there'd be options for enabling and disabling groups as well. I think the ASCII/Unicode option should be called something different, as it affects more than just the borders.

[darkliquid]

I wonder if taking an approach similar to git-log's format:<format-string> directives might be warranted?

For example, a possibility:

echo -n "0123456789ABCDEF" | hexyl --format="<%8bx | %8bo(:)> [%8c(_) %8c(*)] offset=%4od"

to specify output like

<30 31 32 33 34 35 36 37 | 070:071:101:102:103:104:105:106> [0_1_2_3_4_5_6_7 8*9*A*B*C*D*E*F] offset=0016

where:

• %8bx denotes 8 bytes in hex separated by a space
• %8bo(:) denotes 8 bytes in octal separated by :
• %8c(_) denotes 8 characters separated by _
• %8c(*) denotes 8 characters separated by *
• %4od denotes a 4 digit long offset in decimal

Obviously this is extremely complicated, especially when taking into account that the format string can effectively specify the frame size, plus that frame size could be split across multiple %bx occurrences, and it would be in theory possible the have 'unbalanced' output where a different number of characters are output compared to the bytes. Very powerful and flexible though (like git's format strings). Could then implement a bunch of defaults in terms of the format strings for predefined 'pretty' prints, much the same way git does.