<div dir="ltr">I've been using hexedit quite a lot, mainly for _corrupting_ files, and<br>have been meaning to send this collection of changes for far too long<br>now. I saw a bug requesting editing in the ASCII pane (which this patch<br>_doesn't_ add), and wanted to get this sent in before it has to undergo<br>the third massive merge conflict of its existence...<br><br>The main "TODO" in this is that I never got round to implementing<br>searching for an arbitrary byte sequence. It seems like we ought to have<br>that feature, but personally I'm far more likely to jump to an offset or<br>to search for some ASCII. I haven't needed to search for arbitrary byte<br>sequences in all this time, so I'll fix this if/when I actually need<br>it...<br><br>* Enter (new) read-only mode rather than refusing to open read-only<br>  files.<br><br>* More keys: page up/page down, home/end, and ctrl-home/ctrl-end for<br>  beginning/end of file.<br><br>* Jump with ^J (or vi-like :). Enter absolute address or +12 or -40 for<br>  relative jumps.<br><br>* Find with ^F (or vi-like /). No support for bytes, but useful for<br>  finding text. (^G or n for next match, ^D or p for previous match.)<br><br>* Support all the usual suspects for "quit": vi-like q, desktop-like ^Q,<br>  panic ^C, or even plain old Esc.<br><br>* The ASCII pane is made more readable by (hopefully) reasonable use of<br>  color. Regular control characters are shown in red using the<br>  appropriate letter (so a red A is 0x01, etc), printable characters are<br>  shown normally, and top-bit set characters are just shown as a purple<br>  question mark (since I couldn't come up with a better representation<br>  that had any obvious value --- in my experience top-bit set characters<br>  are either meaningless in ASCII, part of a UTF-8 sequence in modern<br>  files, or in some random code page in ancient files). The choice of<br>  red and purple was to deliberately make these not-actually-ASCII<br>  characters slide into the background; before this patch they have so<br>  many bright pixels (especially with the use of reverse video) that I<br>  couldn't clearly see the *actual* ASCII content in the ASCII pane.<br><br>* Addresses are now shown in yellow. No real justification other than "it<br>  looks nice".<br><br>* NUL bytes in the hex pane are shown dimmed. I find this helpful<br>  especially when there's a lot of padding, and it can actually be a<br>  useful clue when reverse engineering (you can "see" repeated patterns<br>  more easily), but I can understand if this one's controversial.<br><br>* Errors are shown "vim style" in bold white text on a red background,<br>  waiting briefly to ensure they're seen.<br><br>* The status bar shows the filename, whether the file is opened<br>  read-only, the current offset into the file, and the total<br>  length of the file.<br><br>* SIGWINCH handling has been added.<br>---<br> lib/tty.c            |   4 +<br> toys/other/hexedit.c | 291 ++++++++++++++++++++++++++++++-------------<br> 2 files changed, 210 insertions(+), 85 deletions(-)<br></div>