|
I've been using hexedit quite a lot, mainly for _corrupting_ files, and
have been meaning to send this collection of changes for far too long
now. I saw a bug requesting editing in the ASCII pane (which this patch
_doesn't_ add), and wanted to get this sent in before it has to undergo
the third massive merge conflict of its existence...
The main "TODO" in this is that I never got round to implementing
searching for an arbitrary byte sequence. It seems like we ought to have
that feature, but personally I'm far more likely to jump to an offset or
to search for some ASCII. I haven't needed to search for arbitrary byte
sequences in all this time, so I'll fix this if/when I actually need
it...
* Enter (new) read-only mode rather than refusing to open read-only
files.
* More keys: page up/page down, home/end, and ctrl-home/ctrl-end for
beginning/end of file.
* Jump with ^J (or vi-like :). Enter absolute address or +12 or -40 for
relative jumps.
* Find with ^F (or vi-like /). No support for bytes, but useful for
finding text. (^G or n for next match, ^D or p for previous match.)
* Support all the usual suspects for "quit": vi-like q, desktop-like ^Q,
panic ^C, or even plain old Esc.
* The ASCII pane is made more readable by (hopefully) reasonable use of
color. Regular control characters are shown in red using the
appropriate letter (so a red A is 0x01, etc), printable characters are
shown normally, and top-bit set characters are just shown as a purple
question mark (since I couldn't come up with a better representation
that had any obvious value --- in my experience top-bit set characters
are either meaningless in ASCII, part of a UTF-8 sequence in modern
files, or in some random code page in ancient files). The choice of
red and purple was to deliberately make these not-actually-ASCII
characters slide into the background; before this patch they have so
many bright pixels (especially with the use of reverse video) that I
couldn't clearly see the *actual* ASCII content in the ASCII pane.
* Addresses are now shown in yellow. No real justification other than "it
looks nice".
* NUL bytes in the hex pane are shown dimmed. I find this helpful
especially when there's a lot of padding, and it can actually be a
useful clue when reverse engineering (you can "see" repeated patterns
more easily), but I can understand if this one's controversial.
* Errors are shown "vim style" in bold white text on a red background,
waiting briefly to ensure they're seen.
* The status bar shows the filename, whether the file is opened
read-only, the current offset into the file, and the total
length of the file.
* SIGWINCH handling has been added.
|
|
Although we can get away with ignoring termcap/terminfo on the output
side by restricting ourselves to generally-supported escape sequences,
the input side is trickier because we need to support the sequences sent
by common terminals. Luckily, this isn't is as bad as it sounds because
only Home/End commonly differ. But it does mean we need a slightly
different implementation to deal with the many-to-one mapping.
Since we can't use TAGGED_ARRAY for this (without inflicting pain on all
the callers) I've also switched to OR-ing in the modifier keys, so we
have (say) KEY_UP|KEY_SHIFT rather than a separate KEY_SUP. This also
generalizes better should we ever need to support multiple modifiers at
once.
To reduce the number of #defines, I've also switched from KEY_F1,
KEY_F2, and so on to KEY_FN+1, KEY_FN+2, and so on. This isn't obviously
necessary, and easily undone if we'd rather have move #defines in return
for slightly more natural naming.
To enable all this, I've inverted scan_key and scan_key_getsize so that
scan_key_getsize is now the underlying function, and we don't waste all
the top bits encoding width and height between scan_key and
scan_key_getsize.
Tested by pressing Home and End in hexedit in all of the terminals
available to me.
|
