Don't clear Undo buffer on Save

[hexaae]

Please, can you add an option (or make it default) to NOT clear Undo buffer on Save?
It is the only uncomfortable thing I've found in HxD compared to other text editors.
Sometimes you need to revert changes after Save, but ATM you can't with HxD 2.5.0.0 Win x86/64.
Very frustrating after a lot of recent changes + Save if you want to just go back a few ones...
Re-loading a .bak won't help as you will loose track of single changes you made, sparse in the whole binary.

Undo/Redo should be always kept in memory till you close the file IMHO, as it would be so useful in many situations...
If you want to add a warning as a precaution "You're about to Undo changes after Save of the current file" would be also ok.

[Maël]

This is a frequent request but cannot be implemented due to large file support.

The changes to a file are stored in a kind of a diff data structure that needs the opened file to remain unchanged, which is why it has to be locked after the first edit.

When you save a file, it gets modified, so any diff data structure will not be applicable anymore.

[hexaae]

It's an important feature.
Hope you'll find a way to implement it rewriting that part, or maybe adding an option, if you can't really change it through temp files or things like that, to load whole file in memory instead of "streaming large files" mode. It's frustrating having 32GB RAM to work on big files and being unable to Undo after save
Have to use online hexed.it for 90% of my usual hex-editing tasks on files to be safe I can test & revert changes easily.

[Paxtez]

Is this why there is no redo feature also?

Obviously we know nothing about how HxD works under the hood. But it sounds like that this diff file is created by the program, couldn't it just update the hash of the file or whatever, to the point to the new file?

[Maël]

As mentioned before, this is due to huge/unlimited file size support.

When you edit a file in HxD the file itself will not be modified until you save it. To store the edits (and display them as if the file was already modified) an efficient diff data structure was designed that holds those changes and still allows quick random and serial reads.

That part was actually one of the hardest parts to design and implement.

The diff datastructure relies on the base file to remain unmodified, which is why the file gets locked once you make the first edit. As soon as the diffs are applied to the file, the diffs obviously becomes invalid.

Using temporary files would defeat the purpose of quickly editing huge files, since it would require a file copy of the entire file first.

Maybe there is a way to translate the diffs based on the original file (undo) into diffs based on the modified and now saved file (redo). I don't remember the details, I think there were some fundamental logic reasons that would prevent that.

The major reason was however that it would still require to keep the file locked, to allow for undos. Since many want files to be unlocked as soon as possible (lots of thought went into optimizing that as much as possible), this would be a major drawback.

Backup files are the compromise.

[hexaae]

The only high quality HEX-Editor I've found supporting SAVE with Undo still working is the top notch, commercial, "010 Editor" from Sweetscape which is not cheap... it offers even too much options and features
However I would pay a few bucks for a Pro version of HxD with this useful feature...

[Maël]

A few bucks would not nearly account for the development time needed

And the editor you mention has other issues in its implementation. The fundamental problems related to locking can not be circumvented, unless the implementation is buggy.