all file contents get overriden in <=16B files

[litoj]

The vital functionality of undoing sth is broken. I somehow accidentally overwrote the entire line with the same hex values and now I have no way to go back.

This is a major problem, since it also automatically saved the file. I have no idea why or how it happened, but I certainly think it should never discard the editing history.

[litoj]

I have been able to reproduce the problem now. When I set the filetype to xxd it automatically starts the plugin. All fine so far. But then when I want to to save it, even if nothing is edited, it ofter overrides the entire file with just one symbol that was at the end of the line, when the file was just one line long (hex line -> <=16 bytes).
It happens with certain types of file contents, the details of which I am not able to figure out, but here is my file contents that caused it (in bytes) A3 90 21 01 FB

[yilisharcs]

Have you been able to reproduce this with more details?

[litoj]

Other than that when I open the file with a maximum of 16B (5B in my case) to fit on one line and the last byte is FB it results in the file always saving the line as all FB overwriting the original contents even without change... No, not really :D

when I refresh the file/buffer it works as it was supposed to. But not on the initial open and :set ft=xxd

[KevinGoodsell]

This appears to reproduce the problem. I think it might be related to character encoding somehow. The test file is detected as latin1. Other test files I've tried behave differently.

echo -n -e "\\xA3\\x90\\x21\\x01\\xFB" > test-file
nvim --clean test-file

:set binary
:%! xxd -g 1 -u
:%! xxd -r
:%! xxd -g 1 -u

After the last command, the xxd output looks like all FBs. Also, if you write after the xxd -r command the resulting file has the final FB removed.

So I don't think the problem is a specific bug in hex, and I don't think it's a bug in xxd. I think it's some confusing neovim behavior around file encodings.

[KevinGoodsell]

Also you can replace the xxd commands with cat: :%! cat. Do it once and some characters change to the <XX> form. Do it a second time and everything is replaced with <fb>.

[KevinGoodsell]

Simplifying the repro a bit:

echo -n -e "foo\\xC0" > test-file
nvim -b --clean --cmd "e ++enc=latin1 test-file"

:%!cat
:%!cat

The first cat changes the presentation of the last character from A with a grave accent to the hex version, <c0>. The next cat changes the rest of the bytes to <c0>.

It seems like the last byte value is key, it appears to only repro with values 0xC0 and up. My suspicion is that nvim is seeing this as part of a UTF-8 multi-byte sequence that never terminates, even though the file encoding is supposed to be latin1.

If you save the file after the first cat, you'll see that the last byte has been removed. That fits with seeing it as an unfinished UTF-8 sequence. As for why the second cat changes all of the characters, I think it must be due to some bad internal state.

[KevinGoodsell]

I think the combination of binary and fencoding=latin1 is key to triggering this problem, which makes it less commonly seen. The reporter's test file happens to be detected as latin1, and nvim sets fencoding accordingly. If the file is opened with the -b option, fencoding is not set and the problem does not appear. If fencoding is manually set to empty after opening the file, the problem does not appear.

It seems like this is a problem in Vim's and NeoVim's latin1 encoding when the buffer contains invalid UTF-8. The tests I've performed seem to give pretty much the same results in Vim 9.0. I haven't tried other encodings, and I haven't found any clear description of the problem.

A work-around for hex.nvim might be to ensure fencoding is cleared. A work-around for users might be to always start with -b.

[KevinGoodsell]

I've had good behavior so far with this patch.

diff --git a/lua/hex/utils.lua b/lua/hex/utils.lua
index b7a8485..f71f4e4 100644
--- a/lua/hex/utils.lua
+++ b/lua/hex/utils.lua
@@ -9,6 +9,7 @@ end
 
 function M.dump_to_hex(hex_dump_cmd)
   vim.bo.bin = true
+  vim.bo.fenc = ''
   vim.b['hex'] = true
   vim.cmd([[%! ]] .. hex_dump_cmd .. " \"" .. vim.fn.expand('%:p') .. "\"")
   vim.b.hex_ft = vim.bo.ft

[KevinGoodsell]

I filed a bug with neovim, including repros and code analysis describing the cause: neovim/neovim#36990

I think this confirms that setting fileencoding to empty should fix the problem. The issues all seem to occur within the UTF-8 to latin1 conversion code.