:wq! should not quit (and lose the changes) if there are no permissions to write the file

[Pistahh]

Summary

I cannot reopen #1575 - but I think the way it was fixed is wrong.
Now `:wq!' still exits when it can't write the file, losing the changes. I think it shouldn't exit. vim doesn't exit.

Reproduction Steps

I tried this:

1. hx /etc/hosts - should be a file without permissions to write it
2. change it
3. try to save and exit with :wq!

I expected this to happen:

editor displays an error message about the permission issue and it stays in the editor, just like vim.

Instead, this happened:

editor displays an error message about the permission issue and exits, losing all the changes

Helix log

No response

Platform

Linux, zsh.

Terminal Emulator

terminator

Helix Version

helix 22.05 (c107f4e)

[the-mikedavis]

This is similar to #1575 but not a duplicate, and still open after the fixes in #2267 and #2359. The write does cause an error but it doesn't prevent the q! part from closing down the editor.

edit: to be clear, #1575 is fixed. This is a separate issue.

[dead10ck]

This may be an issue of semantics? My expectation would be that the ! indicates "just quit no matter what". If you actually do care about catching errors, then I think wq is more appropriate.

[the-mikedavis]

Hmm yeah it's a bit murky - I would say we should interperate the ! as belonging to the w but that doesn't cover the case of other buffers not being saved.

Based on the behavior of kakoune and vim, I think :wq! should...

• not exit if writing the current file fails
• exit if writing the current file succeeds
• exit if any other buffers open are modified without saving them

[dead10ck]

This seems inconsistent though. Why is it that the command would care about losing changes to the current buffer, but we don't care about every other buffer? Like what if you have one file read only and one you do have permissions for, and you modify both, and then wq!? Why is the behavior different depending on which of the buffers is in view?

The way I see it, either you care about losing changes or you don't.

[the-mikedavis]

For caring about other buffers than the focused view we have :wqa/:wqa!. For exiting without caring about any of the buffers we have :q!. If :wq! can exit without saving, there isn't much point to the command compared to :q!

For me it's a fairly common workflow to temporarily modify a few files (usually at least a scratch buffer) and then edit the main file I care about, ending the session with :wq! to save the main file and discard the scratch

[dead10ck]

Yeah that's a good point. If no one picks this up before I get to it, I can include a fix for this in #2267. Should be a quick change.

[Pistahh]

In vim, :wq! only writes and closes the current buffer but the editor remains running if there are other buffers. So in vim there is no way to lose unsaved data if there is a w in the exit command, not even with !.

I personally tend to forget about other buffers or even about saving them. In Vim, even with :wq! I get reminded about these - as only the current buffer gets saved and closed, the editor with the other buffers remain open.

Yes, helix :waq somewhat covers these, but what if I don't want to save everything but rather just reminded that they are still there?

Also, note that it is unclear what the ! actually causes. Consider this:

Scenario 1:

I'm running hx /tmp/a.txt /tmp/b.txt.
In the editor I change a.txt, then switch to b.txt and I change it too.
Then I use :wq - it saves b.txt, closes it and reminds me that a.txt is still there, and switches to it. All right, I'm reminded that
something still needs to be taken care of. I can still decide to save or discard those changes in a.txt.

Scenario 2:

I'm running hx /tmp/a.txt /tmp/b/c.txt - and assume /tmp exists but /tmp/b doesn't.
In the editor I change a.txt, then switch to c.txt, change it.
When I try to save it with :wq it complains that the path /tmp/b doesn't exist so it can't save the file.
Ok, then I will do it forcefully, as I know it will create the directory, so I use :wq!. Indeed, it creates the directory, saves the file, and boom, also exits the editor. And whatever I did to a.txt is lost.
So the ! in the command didn't just force what I wanted (to get the path created) but also it had a side effect I wasn't even aware of.

Therefore I really think whatever the behaviour of :wq! should be, it definitely shouldn't lose data.

[dead10ck]

Yeah, and actually thinking some more about @the-mikedavis 's case with scratch buffers, the use case might be different. Losing changes in a scratch buffer is not the same as losing changes to a file on disk. Actually, I believe kakoune does not stop from quitting if there are unsaved changes in a scratch buffer even without the !.

I think maybe the core of the issue is the user's expectation of what the ! should mean. Does it mean:

• I don't care about errors, just try to write if you can and quit even if it fails (current behavior)
• Write the current buffer and make sure that works and then quit, but I don't care about any unsaved changes in other buffers (kakoune's behavior)
• Write the current file and make sure it succeeds, and if the parent directory doesn't exist, create it, and also error if there are unsaved changes in other buffers (therefore the only meaning of the ! is to create the parent directories if they don't exist)

@archseer any thoughts?