https://github.com/ndd7xv/heh/blob/9970480f2cb0825e918c268bb8b02b80d5b5ab5c/src/app.rs#L64

This line is crashing at startup for my shell which does not support clipboard interaction.

A common way to avoid the crash is to use this pattern instead of unwrap():

clipboard: Clipboard::new().unwrap_or_else(|e| {
    eprintln!("Failed to construct a Clipboard object: {}", e);
    std::process::exit(1)
}),

Hello,

When I ran in your repo few days ago, I wanted to try the tool but realized there was no sample data anywhere that could help me to test your tool.

Since I had no data to test the tool on either, I couldn't test.

Maybe it would be a good idea to add sample data for people that just want to have a look on your project ? :smile:

Hi, Thanks for heh -- it's a cool tool for viewing hex data, just like less is for text.

Just added navigation when inside of Hex window, to align with other traditional Unix tool.

hjkl - for arrow navigation ^, $ - for start / end of line q - to quit, without any modifier

It made sense to me for two reasons:

1. The first time I tried heh it felt lightweight, like less, so to quit I just went for muscle memory hitting 'q'.
2. When typing non-hex chars inside Hex window, you just get an error notification -- we can do better by responding to these specific keys, which are already popular bindings in Unixy tools

Suggested in a Reddit comment, but putting it here if there are any ideas.

I think it'll be complicated to do this, and I don't think many hex editors support Unicode. Many files inspected with a hex editor (such as binaries or specific file formats) often have random bytes that are not ASCII printable but also not Unicode. Thus, there probably needs to be a way to differentiate between a byte stream that can represent Unicode and just a byte stream that's random bytes.

There may also be other concerns that aren't coming to mind right now.

In larger files, keying your way to the selected byte isn't going to cut it. GHex has a "Goto/Jump to Byte" feature that allows a user to input a byte they want to select - it can interpret decimal or hex (e.g., 10 or 0xA). The shortcut to use it is Ctrl+J.

I'm thinking that this could be done by creating a popup (example), though I'm open to other ideas - having text input update in the "Notifications" label wouldn't sound half bad if it weren't for the fact that I called it "Notifications."

This currently allows dragging in the viewports to hilight a selected area. In the future, this should allow for copy and paste of hex and ascii, as well as mass deletion.

Background

heh currently has no way to undo a deleted or back-spaced byte. It would also be convenient for users to "un-type" things are go back to a position the cursor was previously located at.

Task

I'm thinking to implement something basic, we could have a Vector of Actions, which would be an enumeration of the different actions a user will be able to undo. Hitting ctrl+z would pop actions from the vector and undo that command, while doing an action would push it to the vector.

Previously, resizing would always keep the starting address of the bytes the editors displayed fixed. This caused problems with how we calculated where to display the offset.

Now, we readjust offset so that 0 is ALWAYS the beginning offset, which not only fixes some bugs but also made me realize I could simplify adjust offset .

The editor only works if the stdout is a TTY device. For example, if we run below command, the editor should exit early and print an error message.

$ heh file > output

Fixes #20

I'd love some (brutally honest) feedback on this refactoring - if it sucks, I want to know because I care about the state of this repository. 5abcc5a2d2a7eec5b1ba867755334ac0d3f5ce53 is probably the most important one. I made a preliminary change to the way input is handled, while also trying to fix up so code/documentation in some places. Predominant goals of this "spike":

Break down handle_input

I changed CI in this PR to make linting run the clippy::pedantic category, and along with fixing a bunch of small things also tried to break down handle_input because clippy complained that the function was more than 100 lines. I think I will try and move the handling into input.rs as seen in https://github.com/ndd7xv/heh/pull/22.

Make future features easier to implement

Instead of a series if statements to determine what the handle_input function should do, I created the trait InputHandler and anything that implements it should be able to uniquely handle input.

My reasoning behind this is that 1) the if logic was hard to follow and 2) as we build out more features (like maybe control+find, or a help "page" which is a popup over the entire screen you can arrow through for information) this makes it easier to have these new features handle input differently.

Make things more readable

Honestly, this might be a mild step back. I had tried to aggregate necessary fields in ApplicationData so that InputHandler's parameters weren't so long, but this leads to an extra step to get to a field (for example, app_info.offset instead of just `offset).

Tried to add some documentation/comments here and there, but it's still very much a WIP.

As a part of my self code-review/ramblings in https://github.com/ndd7xv/heh/pull/19, the input is being handled based off of the FocusedWindow is becoming too long and should be refactored.

One potential solution is using traits, described in https://github.com/ndd7xv/heh/pull/19#discussion_r948092282. We could also just keep Popup(PopupData) in the enum and impl each case.

Welcoming other suggestions as well! :smile:

Background

If you run something like

kill <heh pid> # which you can probably get with $(ps -ef | grep heh | grep -v grep | awk '{print $2}')

heh will terminate and fail to save any progress or changes made. It will also remain with raw mode enabled, rendering the terminal session extremely difficult to use.

Task

When running the command mentioned above, heh should have some sort of graceful way of preventing data loss, or at least a way to alert the user and leave the terminal session usable. Doing the same thing for vim prints out

Vim: Caught deadly signal TERM
Vim: preserving files...
Vim: Finished.

For saving things, we could try using .swp files.

As per this feedback,

• Give more spacing between functions
• Add comments to generate rustdoc
• Add additional comments on obscure code

I'm extending this beyond the listed recommendations because the suggestions are a part of the bigger idea to make this repo understandable - if there's anything that needs to be changed (or you think should be added) in the README, typos in a comment, or a refactoring of unidiomatic/messy code, those changes (whether they be in a different PR or not) are welcome to reference this issue.