Package for printing and annotating hexdumps

Hi,

I've been building a package for showing hexdumps [1,2] with the capabiliti=
es of TikZ. Right now I'm nearing the state where I'd do the initial releas=
e (I didn't release it publicly yet). But before I release (and have to be =
careful with breaking changes), I wanted to ask some people for feedback.

(you can find the source at [2])

There are a variety of aspects on which I'd be grateful for feedback (order=
ed in terms of estimated effort):
1. I'm not even sure on the package name as of now. Right now it is called =
"hexdumptikz". Does this name make sense to you and/or do you have ideas fo=
r another suitable name?
2. Similar to 1.: Currently I'm using the expl3 prefix "hexdumptikz". Initi=
ally I thought of using just "hd" but I thought maybe a just two character =
prefix isn't suitable for such a more special interest package (and I thoug=
ht it'd be nice for the packagename and the prefix to be matching). On the =
other hand, the smaller the prefix, the shorter the function-names and the =
easier it is to format and read the `.sty`. This especially is true as the =
package contains of multiple sub-modules/packages further building upon the=
 "root-prefix". Any opinions on this?
3. Any feedback on the usage and the user-docs of the package is very welco=
me (`hexdumptikz.pdf`). While I plan on renaming a few keys ("addrs" -> "ad=
dr" and "byte styling" -> "styled bytes") and adding some keys customizing =
the hexdump-parser generally I think of the user-interface as fixed.

4. This is my first package written in expl3, so any feedback on my expl3 u=
sage would help me learning best practices (I already ran explcheck). But I=
'm of course aware that with 5278 lines of dtx in total probably none of yo=
u will read the entire source. But I tried to do a nice split into sub-modu=
les/-packages which are as self-contained as possible explaining the relati=
on of the sub-modules/-packages in the dtx-docs (`hexdumptikz-code.pdf`).

5. and of course any other feedback is appreciated as well

(Note if you're reading the code, you might wonder at some places why some =
parts regarding addresses are a bit lengthy and cumbersome. The reason here=
 is that the package should also support addresses like 0x7fffffffee10 whic=
h do not fit (too large) into an expl3/LaTeX integer. Thus, I tried to avoi=
d calculations if possible and if needed only consider the last few digits)=
.

The things currently left on my Todo-list are
- slightly adjust and add some keys for the user interface
- register the expl3 prefix (only after the prefix is fixed and I think the=
 package needs to be released on CTAN first)
- avoid placing debugging code in the final sty (instead generate special d=
ebugging sty files with the help of dtx -- using [3] as inspiration)

Feel free to open issues at [4] or directly contact me via e-mail (l.mail.n=
[email protected] or [email protected]).


[1]: https://en.wikipedia.org/wiki/Hex_dump
[2]: https://codeberg.org/atticus-sullivan/hexdumptikz
[3]: https://codeberg.org/cfr/prooftrees/src/commit/fb65220759cb03d15022177=
8ccecb8f82be382d9/prooftrees/prooftrees.ins#L64
[4]: https://codeberg.org/atticus-sullivan/hexdumptikz/issues


Best regards and thanks for reading
Lukas