Remote editing wipes out .go files with go_fmt_autosave enabled.

[mk23]

Bisecting revealed this commit to be the culprit: 54946ea

I use vim as my IDE and often use netrw(scp) for editing files on remote servers. I recently updated vim-go bundle and now every time I write the buffer out (ZZ or :w) the resulting file on the remote is completely wiped out. This only happens with auto gofmt is enabled.

Repro

Prerequisites

1. any machine with ssh+key auth
2. vim-go installed with g:go_fmt_autosave = 1
3. gofmt or goimports doesn't make a difference

Steps

1. $ vim scp://localhost/foo.go
2. enter some content, i.e. package main
3. save buffer (:w)

Observed

• The resulting document is blank

Expected

• My code, that I worked so hard on, must continue exist but with better formatting. 😁

[guns]

Didn't think about netrw with that commit! Looks like this can be hacked around by writing to b:netrw_tmpfile. I'll take a stab at it now.

[fatih]

That's an interesting issue :) @guns are you're working on it? If not let me know please.

[guns]

@fatih: Yes. I have found a couple of options, but I'm afraid I won't have time to write a solid patch until tomorrow.

[fatih]

@guns no worries! Take your time. I just wanted to be sure if you're working on it :) Thanks on tackling this problem 👍

[codeactual]

Just in case it's helpful for the patch, I also ran into revert/wipe symptoms in local file scenarios.

My setup

• vim 7.4.052-1ubuntu3
• vim-go settings are default except for g:go_highlight_* are all enabled
• syntastic bundle removed entirely just for testing this

Scenarios

These appear 100% reproducible for me in the cited 54946ea (but not in the prior commit) and current head (4de4eeb).

New file

Open a new file and add some code. A save (:w) or format (:GoFmt) operation will empty the buffer.

Existing file

Open an existing file that only contains "hi" and add some code. :w/:GoFmt will revert the buffer back to "hi". "hi" can also be replaced by pre-gofmt-ed and compilable code.

Caveats

• Errors prevent it. If gofmt finds an error like expected 'package', found 'func', nothing is wiped/reverted erroneously.
• vim-session hid this issue from me until today. I'm not able to reproduce it in buffers auto-opened by vim-session. For example, if I open the "hi" file above, quit (with auto-save enabled), reopen, replace "hi" with some code, nothing is wiped/reverted erroneously.

[mk23]

Has there been any progress with this bug? I'm happy to test any experimental changes.

Thanks.

[fatih]

@mk23 not yet on my side as I was clearing my backlog. Just arrived at this issue. @guns do you have any kind of patch (even though it's not finished) ? If not I want to look at this problem.

It's really frustrating that Vim makes it so hard to rewrite/update the content of a buffer. Every single step we make to improve the situation makes something else worse.

[junkblocker]

I've run into this multiple times with local editing. After losing the file content and all vim undo information to this, I was lucky to be able to dig into my undo folder manually to recover the content from the last saved file. This is scary. Can I request to prioritize this data loss issue over any features or less important issues, please?

[guns]

Forgot about this. Like I mentioned before, writing to b:netrw_tmpfile in fmt.vim will work. @fatih has also said he might accept an optional python formatting route for compatible clients; this would also fix this issue.

I will try to find the time today for this patch, but if I haven't posted a PR by the end of the day, I assure anyone reading that this is a relatively easy fix.

[guns]

I assure anyone reading that this is a relatively easy fix.

Okay, having just spent a few minutes with this problem, I remember now why I never sent a PR.

We rename(formatted-source-tmpfile, current-file) in go#fmt#update_file, but expand('%') in a netrw buffer returns a url like scp://host/path. Simply writing to b:netrw_tmpname does not work and there are no documented ways to resolve this problem in :help netrw. There is very likely a way to hack our way around this, but it would rely on undocumented implementation details in netrw.

AFAICT there are two solutions to the issue of netrw buffers:

1. Write the python formatter discussed in the past and make it mandatory for editing netrw buffers. Everyone who has('python') will also be upgraded to this code path for normal go buffers.

2. Restore a version of the old algorithm for netrw buffers only.

I'm in favor of option 1 and would be happy to submit a patch for it.

[junkblocker]

Just to be clear, I have this problem with local buffers and netrw buffers are not the complete problem. The bug title should be changed to remove 'Remote' as it gives a false sense of rareness of the bug. It may be the reason why this is the oldest bug open. Until this is fixed I'm forced to use something other than vim-go 😢 .

PS: It's possible that netrw interaction may be due to me using vimfiler which has to mess with netrw in the background.

[eyJhb]

@guns could you submit a patch for this? Currently working on a project, where I really need this.
Please let me know, if you need any help with this.

Same goes for you @fatih :) Would really enjoy seeing this issue resolved