Allow `--wait` flag to work with split editors

[haudan]

Type: Bug

This is a reopening of #150368, which was not interpreted as a bug. It is a bug.

The --wait or -w flag behavior is unexpected and probably broken in combination with split editors. The --help output says this:

Wait for the files to be closed before returning.

This description is ambiguous in relation to split editors. In fact the implementation doesn't do the "common sense" thing, which is to wait for the user to be done editing, but instead waits for a "lowlevel" editor closure event, which isn't useful behavior. The only trustable signal that the user is done, is when they have closed all editor instaces of the file(s) supplied from the command line.

This unexpected behavior can lead to genuine problems, even data loss. Consider using VSCode as a git commit messag editor. The official documentation states to use the --wait flag. Consider the following steps (reproducable):

1. Invoke git commit. VSCode opens with COMMIT_EDITMSG and Git says hint: Waiting for your editor to close the file...
2. Split the editor (horizontally or vertically).
3. Edit and save the commit message.
4. Close one of the editors.
5. Git's code --wait invocation completes and applies the commit. If our git commit terminal is behind our VSCode window, we have no idea that this happened.
6. We still have COMMIT_EDITMSG open and can edit it, oblivious to the fact that we have already committed.

Therefore: VSCode interprets editor closure, which naturally happens when rearranging the editor layout, as editing-completion.

This is just an example with git, where of course the commit message can be amended. However, other tools invoking VSCode with --wait can and do cause much more severe problems.

Interestingly, the documentation linked above describes different behavior, when it says (emphasis mine)

When you launch VS Code from the command line, you can pass the --wait argument to make the launch command wait until you have closed the new VS Code instance.

which leads to further confusion.

What's also confusing is that VSCode behaves differently for unsaved editors. Repeating the above git example, but not saving in step 3, actually yields the expected behavior of code --wait not completing. A code editor must not make any assumptions about the user saving. The behavior for saved and unsaved split-editor-closure should be identical.

VS Code version: Code 1.74.2 (e8a3071, 2022-12-20T10:29:14.590Z)
OS version: Windows_NT x64 10.0.19044
Modes:
Sandboxed: No