Saving while continueing to edit the buffer overwrites the post-save changes

[DanCardin]

https://user-images.githubusercontent.com/701548/156816518-e3abded8-1400-41ca-85f8-6d9b639d990a.mp4

The actual buffer that gets saved seems to be the pre-format version, which makes sense because of the fact that it's using BufWritePost (btw, could it possibly be BufWritePre, so that one ends up with an unedited buffer after saving), fwiw.

[CKolkey]

Seems like this can be corrected with if vim.fn.mode() == 'n' and (check changetick hasn't changed) in the handler callback function.

[DanCardin]

That's probably a decent idea anyway, but i can equally repro by saving then quickly pasting or doing other normal mode things.

Ideally it would no-op if the state of the buffer had changed at all from the savepoint, although i dont know the practicality of doing so.

[lukas-reineke]

The actual buffer that gets saved seems to be the pre-format version

This is by design, it is unrelated to BufWritePost and BufWritePre. Formatting is done asynchronously, so the buffer is first saved like it is, then formatting is triggered, once the formatting results come back the plugin checks if it's safe to overwrite the buffer and write it again.

Ideally it would no-op if the state of the buffer had changed at all from the savepoint

It should do that. I use changedtick to check for changes, but it looks like that is not updated while you are still in insert mode. Like @CKolkey said, the plugin needs to check that as well. This should be an easy fix.

[lukas-reineke]

Can you test if https://github.com/lukas-reineke/lsp-format.nvim/pull/22 fixes the issue?

[DanCardin]

I believe i'm still seeing it happen

[lukas-reineke]

Are you sure? I can't reproduce it anymore.

[lukas-reineke]

I release #22 now, but please open the issue again if you can still reproduce it.

[DanCardin]

I switched back to master and can confirm that my git log contains the commit. I dont know if there's a way for me to manually verify that it's being picked up correctly.

But the above example repro behaves similarly, but not the same

https://user-images.githubusercontent.com/701548/157052592-4886e834-e2e4-40c8-8686-818fc5197386.mp4

[lukas-reineke]

hm, can you add some logging to try to debug this?

Can you print the output of vim.api.nvim_get_mode().mode here https://github.com/lukas-reineke/lsp-format.nvim/blob/68f616555494a01acdba99da3c00dd339da3b140/lua/lsp-format/init.lua#L24-L28

        print(vim.api.nvim_get_mode().mode)
        if
            vim.api.nvim_buf_get_var(ctx.bufnr, "format_changedtick")
                == vim.api.nvim_buf_get_var(ctx.bufnr, "changedtick")
            and not vim.startswith(vim.api.nvim_get_mode().mode, "i")
        then

[DanCardin]

Okay, adding the print (or rather vim.notify) actually lead me down a path. I think your pr did fix it, it just wasn't being picked up despite the on-disk code being changed. some combination of packercompile and lua caching which i cleared eventually made the notify show up and it now seems to be working. Sorry for the false alarm!

I was esp thrown off by the seemingly different behavior to what i was seeing originally.