vm-quit-no-change no longer prompts if unsaved changes exist

[John Hein]

If you have changes in a folder, doing 'x' (vm-quit-no-change) no longer prompts for verification. It just quits without saving any changes. It used to prompt: "There are unsaved changes, quit anyway? (y or n) " as recently as 8.1.1. I tested various trunk versions from 1074 to 1230 (the latter is essentially 8.2.0a) - all of which no longer have the prompt (to protect against accidentally hitting 'x').

I tested this on a small (one message) folder. While visiting the folder, I changed an attribute (vm-set-message-attributes) and hit 'x'.

[John Hein (xpqheqdvq4)]

I see that setting vm-confirm-quit to 'if-something-will-be-lost restores the previous behavior (at least it seems more like the previous behavior in quick testing). I think it would be a better default than nil since 'x' is so easy to hit and because this setting would reflect previous behavior of vm (i.e., would not be a POLA violation).

Ah, I see now. The rev that changed the behavior was 1021. In rev 1020 and before, describ-variable shows that the default setting for vm-confirm-quit is 0 (which is not even a legal value and the customize interface reports that as a mismatch). Since the setting is neither t nor nil, the code acts the same as if 'if-something-will-be-lost is the setting.

In rev 1021 and later, the default setting for vm-confirm-quit is nil. And that setting ignores unsaved changes such as attribute changes in the code executed by vm-quit-no-change.

So, pre-1021 code didn't set vm-confirm-quit to a legal value (probably not on purpose). This wound up having the same effect as 'if-something-will-be-lost. My vote would be to set the default to 'if-something-will-be-lost before the official 8.2.0 release. That would be the least surprising end effect from the user's point of view - and is the safest setting because 'x' is so easy to hit.

Patch attached...