Live data from Hacker News

Your hex editor should color-code bytes

simonomi.dev

21–30 of 165 posts

Re: Your hex editor should color-code bytes

#21

That said, even colored these dumps still feels unappealing to me — so yes this is admittedly subjective gut jumping in the conversation. I get that occult form can also be an attractive force. The post put on the table an interesting point about how to improve the presentation layer to fit what’s human cognition is good at spotting (in general, or at least for the expected audience with some training). And it does s…

> Actually why do we even have rendering with [012345678ABCDEF], when a specific set of (colored/imaged?) glyphs would be able to make more obvious what’s on the table?

Most of us have internalized the relationship between digits in [0-9] for a very long time. Adding 6 more glyphs after that is quite easy (and they're also somewhat well known in the world), and after a while you stop even thinking about the glyphs consciously anyway. A hex 'C' intuitively means to me '4 from the end'. A hex 'F' intuitively means to me 'all 4 bits are set to 1'. I don't see any advantage to switching to a different glyph set for this base, other than disruption for disruption's sake.

> Or even beyond the hexadecimal grouping, wouldn’t be more relevant to render something "intuitively" far more easy to grap without several layer of internalized interpretation through acculturation?

Modern computers deal with 8-bit bytes, and their word sizes are a multiple of bytes - unless you're dealing with bit-packed data, which is comparatively rare (closest is bit twiddling of MMIO registers, which is when you sometimes switch to binary; although for a 4-bit hex nibble you can still learn arbitrary combinations of bits on/off into its value).

This means you can group 8 bits into 1 digits of 8 bits as one glyph (alphabet too large to be useful), 2 digits of 4 (hex), 4 digits of 2 (alphabet too small to give a benefit over binary) and 8 digits of 1 (binary). Hex just works really well as a practical middle ground.

Back when computers used 12 bit words (PDP-8 and friends) octal (4 digits of 3 bits represented in the 0-7 alphabet) was more popular.

Re: Your hex editor should color-code bytes

#22
Why did author decide that best way to demonstrate his idea would be by cutting contrast in half?

color-coding might be a great solution, but you don't really know beforehand which byte values are important. Manually selecting C0 to make it stand out it just ctrl+f with extra steps. (But I wouldn't mind something like "color 00 separate from ascii separate from the rest)

Re: Your hex editor should color-code bytes

#23
For anyone who regularly has to look at/analyze binary files, i highly recommend ImHex [1].

Its a hex editor built with imgui and has a lot of built in tools. Imo the best feature is the data structure editor. You can write a data type definition similar to C and it overlays it on the hexdump and parses it in a structured way while you type.

It also has a node based editor.

1: https://github.com/WerWolv/ImHex

Re: Your hex editor should color-code bytes

#25

Why did author decide that best way to demonstrate his idea would be by cutting contrast in half? color-coding might be a great solution, but you don't really know beforehand which byte values are important. Manually selecting C0 to make it stand out it just ctrl+f with extra steps. (But I wouldn't mind something like "color 00 separate from ascii separate from the rest)

> Manually selecting C0 to make it stand out

That's not what they did, actually. C0 is the only byte in there that's above 3F or so, and it's far from it. Hence the very different colour, and the lack of contrast between the colours of the other bytes.

Re: Your hex editor should color-code bytes

#27
post #18

> it’s much easier to pick out the unique byte when it’s a different color! human brains are really good at spotting visual patterns—given the right format Don't really see the advantage. Unique bytes have no unique meaning across data types. The only good syntax highlight to me is 00 and perhaps FF. But that's my opinion of course. Anything else that has no direct relation to what you're looking at is meaningless.

It would be interesting to do a heat map coloring based on frequency of that value.

Re: Your hex editor should color-code bytes

#28
I actually stopped reading after the intro because I fundamentally disagreed with its premise. The "find the C0" took me about 1/4 second with uncoloured. Looking at the coloured took my eyes about 3 seconds to recover from the colour overload, then I was scanning down and found the colours so distracting with the constant switching between orange, pink and yellows than it took me a total of about 5 seconds to scan down as far as the blue C0. Maybe if it was all uncoloured and blue just for that, I might have actually noticed it looking different earlier.

It's been a while since I used hexedit on Linux, but I think that highlighted search results in reverse colours, just like less does for text search. Personally, I'd prefer that to colours.

Re: Your hex editor should color-code bytes

#30
post #18

> it’s much easier to pick out the unique byte when it’s a different color! human brains are really good at spotting visual patterns—given the right format Don't really see the advantage. Unique bytes have no unique meaning across data types. The only good syntax highlight to me is 00 and perhaps FF. But that's my opinion of course. Anything else that has no direct relation to what you're looking at is meaningless.

> The only good syntax highlight to me is 00 and perhaps FF. But that's my opinion of course.

Would probably make the most sense to have various ranges you can enable depending on what you’re looking for (or to look for patterns) e.g. for single byte coloration I could see

- nul

- printable / non-printable ascii

- non-ascii

- UTF8 leading / continuation

- separators

- start/end pairs (both printable and non printable)

Post reply on HN