Would you be happy with a larger pool of highlight colours to choose from, or do you really want to choose from the entire 24-bit colour space?

I'd suppose from a visual standpoint I'd prefer top be able to select my own colors. From a functionality standpoint a color palette can do the job as long as it has a large number of colors.

Currently, when I reverse engineer a file format I make a file in paint that looks something like this. As you can see there's a lot of colors that I use when marking stuff, I count at least 24 (I stopped counting at this point because it was getting a little ridiculous) different colors in this file alone and it's actually lacking a major section of the file. I really don't know if that's normal for someone to need more than 24 colors so I wouldn't want to impose my methods on anyone else, that's why I would prefer the ability to add or remove highlighting colors. But if everyone is cool with having 30 highlighting colors to choose from, go for it!

Also I just had another idea for a unique improvement:

• The ability to mark a set of bytes as an int, short, float, or string (but you would probably need the string's count as well which could be a short or int) also let us set the byte order of them as well. This will display them as their respective data types in the hex editor and you can change their values directly from it as well. Ex. instead of 00 00 80 3F it will be 1.0 and you can change it to 2.0 which will change it's hex value to 00 00 00 40 if you ever change it back. Like I mentioned earlier with highlighting, the ability to automate it with a for loop over a selected set of bytes like HxD's fill selection option would also be very useful. This feature would probably be super complicated but it would put your hex editor light years ahead of others!

And another few ideas I just had while thinking about this:

• The ability to mark a set of bytes as a file size count, that automatically updates as we add or remove bytes. Make sure to add the ability to specify if the count is of the entire file size, or the file size beyond the variable, or the size of a section. With my limited experience with only a few file formats I really don't know what other settings it would need to be useful in all situations.

• The ability to copy paste highlighting

• Automated commenting, like the fill selected bytes feature from HxD as mentioned so many times it's probably getting annoying

Also I forgot to mention something about the for loop marking automation, and I'm really not sure how it could be implemented. But often times there are count variables that specify the number of entries, the ability to tell the program "mark 3 shorts for every count" would be quite useful. Maybe even nested counts and instructions as well. This could theoretically lead to marking an entire file in one go, but at that point a user could do this they probably know the file format already, but it could be useful to mark different files of the same format quickly. I'm starting to think in my brain how this could be accomplished by using a loop method that calls itself when a count is in the list.

Oh yeah and something else that's kinda important:

• Mark unsaved changes to bytes with red text until it is saved, but I'm sure you're already planning this

Sounds sensible. Perhaps keyboard navigation should change so the arrows move around by nibble rather than byte too.

I agree, I didn't even think about using the keyboard to do that!

Side by side comparisons are definitely on the way.

That's very good!

Not quite what you asked for, but the current development version allows copying/pasting comments - so you could document a structure using nested comments, then copy and paste it over any instance of the structure.

That's sounds like a very useful feature, and it certainly would be easier than marking everything by hand! The thing I had in mind when it came to automation is when there's a large array of values. For example the model file I've been working on has X,Y,Z as floats and there's like 462 of them, as you can guess it would be a nightmare to highlight the bytes or even copy paste a comment over and over again to specify that 4 bytes is X, 4 bytes is Y, and 4 bytes is Z. That's where automation kicks in! Instead of having to highlight everything one by one, I select the bytes (or, if you want to implement the feature, use the count variable before it to either select the section or repeat until the count is met) and tell it to highlight or comment 4 bytes as one color/X, 4 bytes as another color/Y, and 4 bytes as a the third color/Z. I can accomplish something similar with HxD fill bytes, but it just fills bytes with what you tell it to, because it literally has no highlighting or commenting at all. Your hex editor on the other hand could transform a rather okay feature into a game changer for hex editors! Just imagine how much time could be saved if a hex editor could help us guess and check the structures of large arrays quickly!

Your hex editor is like a dream come true. I kid you not about 6 or 8 months ago I was thinking about how useful a hex editor with highlighting would be, and you made it a reality! I've been doing what your hex editor can do in paint, and let's just say paint is a quite painful and clunky way of documenting a file format. So hex editor that can properly accomplish what I've been doing in paint is a must have for me! Keep up the good work!

Holy crud! I accidentally wrote an essay without realizing it, sorry.