Re: [Discussion] Side-by-side dump format

[Jose E. Marchesi]

>> One aspect of this approach that worries me is that there is no visual
>> indication of where each field starts/end if poke is built without
>> styling support... there ought to be some way to overcome that.  Ideas?
>
> So, fun story, I was wondering why libtextstyle doesn't exist on Arch
> Linux and why my poke didn't have styling before: apparently it's
> disabled:
>   # Do not build libtextstyle, as it depends on libcroco
>   # which is now unmaintained and has known security bugs.
>   # patch from Fedora
>   patch -p1 -i $srcdir/gettext-0.22-disable-libtextstyle.patch
> I had to get out Nix to test this one, which was easy enough ^.^

Yes... I think that Bruno has a plan to fix that situation with licroco.
Debian also ships a poke without styling for exactly the same reason.

> n.b. I wonder if --color=yes should emit a warning if you have a poke
> compiled without colour support. I was quite confused earlier having
> it not do anything.

Good idea.  I will add one.

> Maybe without styling support, it could stick the things below the
> lines? At least it's something [could do this with nicer line drawing
> characters than I did, ├──┤e.g.].
> Algorithm:
> - print spans
> - go through field by field, place them starting at the first line. if
> there's something there already advance a line till there's space.
>
> (poke) dump :val x
> 76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
> 00000000: 0a0d 0d0a 6000 0000 4d3c 2b1a 0100 0000  ....`...M<+.....
>           |-------| |-------| |-------| |--| |--|
>           \- typ    \- len    \- byte_order  \- minor
>                                         \- major
> 00000010: ffff ffff ffff ffff 0400 3a00 4564 6974  ..........:.Edit
>           |-------|                |-------------
>           \- section_len           \- 6=opts
> 00000020: 6361 7020 2857 6972 6573 6861 726b 2920  cap (Wireshark) 
>           ---------------------------------------
> 00000030: 342e 302e 3520 2847 6974 2076 342e 302e  4.0.5 (Git v4.0.
>           ---------------------------------------
> 00000040: 3520 7061 636b 6167 6564 2061 7320 342e  5 packaged as 4.
>           ---------------------------------------
> 00000050: 302e 352d 3129 0000 0000 0000 6000 0000  0.5-1)......`...
>           ----------------------------| |-------|
>                                         \- len2

This is a nice layout.  I would prefer it to the markers below.

> Another idea: make the gutters bigger and use markers in them:
>
> 76543210  0011  2233  4455  6677  8899  aabb  ccdd  eeff  0123456789ABCDEF
> 00000000:<0a0d  0d0a>[6000  0000]«4d3c  2b1a»{0100}<0000> ....`...M<+..... 
> <typ> [len] 2=«byte_order» {major} <minor>
> 00000010:<ffff  ffff  ffff  ffff>[0400  3a00  4564  6974  ..........:.Edit 
> <section_len> [6=opts]
> 00000020: 6361  7020  2857  6972  6573  6861  726b  2920  cap (Wireshark) 
> 00000030: 342e  302e  3520  2847  6974  2076  342e  302e  4.0.5 (Git v4.0.
> 00000040: 3520  7061  636b  6167  6564  2061  7320  342e  5 packaged as 4.
> 00000050: 302e  352d  3129  0000  0000  0000]<6000  0000> 0.5-1)......`... 
> <len2>
>
>>
>> Will stop now to wait for your feedback :)
>>
>
> This honestly looks *really* awesome. I like the format, but I do find
> that I sometimes lose track of the structure and types with it. This
> might be partially because the terminal I use day to day (I use neovim
> :terminal as a terminal multiplexer, because I am weird) doesn't do
> hyperlinks, so I haven't tried out that bit yet.

I mainly use M-xshell in Emacs.  I hacked it to support terminal
hyperlinks.  Maybe neovim could be taught about hyperlinks as well ;)

> Here's some idle noodling to try to expose more details without
> putting too much in: adding braces to try to show the structure,
> allowing nested fields to appear. I also stuck the structure type on
> top of the first line because there was free space there, and for some
> reason I tend to forget the types of things immediately.

I will change the prototype to add the name of the type, as it is very
true there is free space there!

As for nested fields, I still think that with good navigation ergonomics
(like adding `dump :val -1' for "last value" for example) their visual
extra complication wouldn't be necessary.

> 76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF 
> (PCAPNG_Shb) {
> 00000000: 0a0d 0d0a 6000 0000 4d3c 2b1a 0100 0000  ....`...M<+..... typ len 
> 2=byte_order major minor
> 00000010: ffff ffff ffff ffff 0400 3a00 4564 6974  ..........:.Edit 
> section_len 6=opts={ opts[] { typ len value
> 00000020: 6361 7020 2857 6972 6573 6861 726b 2920  cap (Wireshark) 
> 00000030: 342e 302e 3520 2847 6974 2076 342e 302e  4.0.5 (Git v4.0.
> 00000040: 3520 7061 636b 6167 6564 2061 7320 342e  5 packaged as 4.
> 00000050: 302e 352d 3129 0000 0000 0000 6000 0000  0.5-1)......`... } len2 }
>
> Another thing: it's confusing that the ascii part is red when one
> colour of the list is also red. Maybe the ascii part should follow the
> colours too, that would actually be quite useful since you can answer
> immediately "what's this string".

Thats easy to add.