fix :wq in remote

[stevenguh]

What this PR does / why we need it:
Fix the issue where :wq can't close a file in vscode remote

Which issue(s) this PR fixes
#3922

[J-Fields]

Thanks!

[suo]

Hi @J-Fields, this change is a regression for me (I actually removed the await in a previous PR to fix the following issue: #3777).

This change causes all saves to block the Vim extension until the save is completed. With the remote development extension, this save can actually take multiple seconds, depending on the connection quality and file size (see the above issue for an example).

I would argue that completely blocking the Vim extension (no shortcuts, no ex commands, etc.) is worse than failing the save in this instance. Especially since :w is likely more common than :wq. Is it possible to revert this PR?

I suppose the ideal solution is to have sequential commands await each other. Or for whatever state machine handles the vim state not block on an ex command finishing. Happy to implement something along those lines if there's consensus on the right path.

cc @jpoon @Chillee

[J-Fields]

@suo Thanks for pointing this out. I think the solution might be to await the save only for :wq, to avoid the race condition while not blocking for :w.

[stevenguh]

Ok. I see where you are coming from. I assumed that's the cost working on remote, because all other write commands like :wa, and :wqa are blocking as well.

@J-Fields That's what I am thinking as well. I am looking into the code. It seems like we can do that.