If I open a file, add a line (o), and then delete that line (dd) making the file exactly the same as when it was opened, upon exiting (:q), Neovim states:

E37: No write since last change (add ! to override)

This behavior did not exist previously. I recently updated some packages though. How can I get back being able to exit without saving after making a change and then undoing that change?

Further Research

If I undo the change (u) instead of deleting the line that was added (dd), Neovim will quit without requiring a save or ! to override.

  • You first say you are deleting the line then you say you are undoing it. Can we assume you really mean undo for both? (Deleting a line you just added isn't the same as undoing it...it won't be back at the original state.) – B Layer Dec 3 '19 at 15:55
  • Note: My comment was sent right before I saw your edit. Sounds like you did mean delete rather than undo. Like I noted, the delete is a new action that adds a node to the undo history. It's not a reversal of a previous action. Thus you must save or force quit. – B Layer Dec 3 '19 at 15:56
  • 2
    I'd like the community's input on this one but I think this question should be closed as it is just the default behavior. – statox Dec 3 '19 at 16:58
  • 2
    I'm voting to close this question as off-topic because the behavior described is intentional and as-designed. – B Layer Dec 4 '19 at 1:42

This is default behaviour of Vim. Vim notices, the buffer has been modified and just warns you of quitting and (possibly) losing your changes. This is done by setting the modified option for the buffer you are currently editing.

However, despite its name, it does not mean that the current buffer differs from the state on disk, but rather whether a change has been done to the buffer being edited, even if it is a no-op, so e.g. r with the same letter the cursor is on, will behave the same and set the modified option, preventing you from an accidental :q.

However when undoing, Vim will reset the modified flag, because this information is also stored in the undo buffer, so that's why it works differently.

It has been requested to change that behaviour (e.g. in this bug), but that would be a backward incompatible change and I tend to agree. In fact, I do actually like this feature.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.