Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your hex editor should color-code bytes

simonomi.dev

Post reply on HN
Print view View original

51–60 of 165 posts

Re: Your hex editor should color-code bytes

#51

Post by Antibabelic »

Someone wrote: post #46

The first example is “go ahead, try to find the single C0 in these bytes” and then argues one should highlight C0 bytes. If that’s true, how does the tool know I will be looking for C0 bytes and not for 03, D3, etc? The logical conclusion of that would be that the hex editor should uniquely color code every byte. And following the other examples even that’s not enough. The proposed solution is to create groups of byt…

I don't think that's quite the point that example was intended to illustrate. The idea is not the you're looking for C0 bytes or any other kinds of bytes in particular, but rather that it's easier to fish out unique and interesting information in a sea of noise when you have color-coded bytes: like the fact that there's a conspicuous lonely C0 or some other value or series of values that stand out.

Re: Your hex editor should color-code bytes

#52

Post by TeMPOraL »

bandrami wrote: post #2

Emacs's hexl-mode does this, incidentally, though annoyingly by default it makes all faces the same color. I never understood why it defines the faces but then doesn't customize them.

What exactly does it do? I'm looking at hexl-mode sources in my Emacs, and I see it defining only two faces - hexl-address-region and hexl-ascii-region.

Re: Your hex editor should color-code bytes

#53

Post by aa-jv »

finaard wrote: post #35
dspillett wrote: post #11

Everything should try do some basic syntax highlighting IMO. Not too much, or it just becomes a sea of formatting that doesn't help at all. It is surprising how much difference just a little splash of colour can make if it isn't overdone. If possible, always include configuration options for the user though, so those with colour-blindness issues can tweak things to their needs, those who are just fussy can make the o…

I'd recommend for every developer to get one or more colourblind friends. I have some, and regularly send them screenshots of what I'm working on to get feedback what they can see and what they can read/can't read. They've been absolutely invaluable for making sure their kind of people can't use my apps properly.

For sure, but if you don't have any friends, don't discount the value of using tools such as CoBlis:

https://www.color-blindness.com/coblis-color-blindness-simul...

.. to get an idea of the impact of your UI design on color-limited folks out there ..

I used this a few times to great effect, it was very revealing to see that my carefully selected teals and ambers were incomprehensible to some folks I really wanted to use my apps .. didn't take much iteration to come to a happy palette though, just needed a bit of care.

Re: Your hex editor should color-code bytes

#54

Post by diydsp »

BigTTYGothGF wrote: post #49
cubefox wrote: post #48

Earlier quoted context omitted.

> Everything should try do some basic syntax highlighting IMO. Interesting idea. So even syntax–highlighting natural language. Grammar highlighting, as it were. Prepositions, verbs, question marks, etc. An LLM could do it. Would it actually improve readability though? Seems likely!

I think that's a good idea, altho you can probably get away with good old NLP to do it.

Were in an era where virtually all sw could have an mcp intf to do anything...not even just color.

Re: Your hex editor should color-code bytes

#55

Post by bombcar »

Antibabelic wrote: post #51
Someone wrote: post #46

The first example is “go ahead, try to find the single C0 in these bytes” and then argues one should highlight C0 bytes. If that’s true, how does the tool know I will be looking for C0 bytes and not for 03, D3, etc? The logical conclusion of that would be that the hex editor should uniquely color code every byte. And following the other examples even that’s not enough. The proposed solution is to create groups of byt…

I don't think that's quite the point that example was intended to illustrate. The idea is not the you're looking for C0 bytes or any other kinds of bytes in particular, but rather that it's easier to fish out unique and interesting information in a sea of noise when you have color-coded bytes: like the fact that there's a conspicuous lonely C0 or some other value or series of values that stand out.

Exactly - though the writing style buries the lede until the end; the recommendation is to have at least a different color for each of the first nibbles (e.g, 0x is one color, 1x another). As a minimum that makes some outliers pop out. He then has other recommendations like highlighting the ASCII range, etc.

As a note, the some up there is load-bearing - color may lull you into complacency where the difference between 01 and 0F is major and important but not highlighted. More complicated regex built color tools designed to highlight "anomalies" could be developed but then you need to define what anomalies are (patters, places where a pattern changes, etc).

Re: Your hex editor should color-code bytes

#57

Post by bombcar »

cubefox wrote: post #48
dspillett wrote: post #11

Everything should try do some basic syntax highlighting IMO. Not too much, or it just becomes a sea of formatting that doesn't help at all. It is surprising how much difference just a little splash of colour can make if it isn't overdone. If possible, always include configuration options for the user though, so those with colour-blindness issues can tweak things to their needs, those who are just fussy can make the o…

> Everything should try do some basic syntax highlighting IMO. Interesting idea. So even syntax–highlighting natural language. Grammar highlighting, as it were. Prepositions, verbs, question marks, etc. An LLM could do it. Would it actually improve readability though? Seems likely!

I don't even seen the paragraphs anymore, just sentence diagrams!

Here's Claud attacking your post:

http://schnecke.bombcar.com/random/sentence_diagram.png

Re: Your hex editor should color-code bytes

#58

Post by cubefox »

BigTTYGothGF wrote: post #49
cubefox wrote: post #48

Earlier quoted context omitted.

> Everything should try do some basic syntax highlighting IMO. Interesting idea. So even syntax–highlighting natural language. Grammar highlighting, as it were. Prepositions, verbs, question marks, etc. An LLM could do it. Would it actually improve readability though? Seems likely!

I think that's a good idea, altho you can probably get away with good old NLP to do it.

Apparently I was not the first to have this thought. See

https://english.edward.io/

https://github.com/SichangHe/natural_syntax

Re: Your hex editor should color-code bytes

#59

Post by randusername »

I think this is a cool idea.

I'd want to take it further by using full RGB and cycling through some colormaps with different properties. Sequential, diverging, cyclic like in matplotlib.

https://matplotlib.org/stable/users/explain/colors/colormaps...

Can't think of a specific use-case off the top of my head, but sometimes I just want the "feel" of the data when I'm plotting something, and maybe the same scattershot approach would pay off at some point on unknown hex data if it was an option.

Re: Your hex editor should color-code bytes

#60

Post by myfonj »

When (rarely) using hex editors, one thing constantly comes to my mind: isn't base 16 arabic-roman numerals a bit awkward for "skimmable" overview? Color-coding indeed helps immensely there, but wouldn't simply letting bits and bops shine in eight bit clusters, resembling the "physical" shape of the eight-bit byte, be somewhat more readable?

We even have characters in the Unicode for representing 0..255 variations, actually two distinct groups: Braille (arguably a bit misuse for binary) and octants (accompanied by older predecessors). So what would be

    |65|97|66|98|67|99|32|126|32|72|101|108|108|111|44|32|109|111|109|33|32|240|159|166|132|
in base-10 or

    |41|61|42|62|43|63|20|7e|20|48|65|6c|6c|6f|2c|20|6d|6f|6d|21|20|f0|9f|a6|84|
in base-16, could be

    |⢈|⢊|⡈|⡊|⣈|⣊|⠂|⡾|⠂|⠌|⢪|⠮|⠮|⣮|⠦|⠂|⢮|⣮|⢮|⢂|⠂|⠛|⣵|⡣|⠡|
in Braille, or

    |𜵲|𜵶|𜴷|𜴻|𜶭|𜶱|𜴀|𜵯|𜴀|𜴋|𜶔|𜴭|𜴭|𜷟|𜴫|𜴀|𜶢|𜷟|𜶢|𜵴|𜴀|(⁕)|𜷢|𜵖|𜴙|
using octants.

Most significant bit is at the top left here, the least one is bottom right -- it felt somewhat intuitive to me this way, your intuition may differ, obviously.

Or, naturally, "AaBbCc ~ Hello, mom! " as a "UTF-8" text.

Try: http://myfonj.github.io/tst/byte-dec-hex-braille-octant.html) Test (with added "CSS" variant and "highlight" of empty dots): http://myfonj.github.io/tst/byte-visualisation-exploration.h...

(⁕) HN apparently eats upper-half block. Amusing that only this particular ("old", as referred earlier) one got filtered out…

Also caveat: Android phones have messed-up Braille block due outdated broken embedded font, so all patterns with dots in the left half appear in the right instead. Long reported, not fixed, IIRC.

Post reply on HN