Comical but infuriating inability to "cancel" from overwriting dialog

[jbclements]

I keep meaning to write a careful "how to reproduce" here, but it's happened to me several times and an ordinary user might well lose her mind and throw the computer out the window when this happens...

In recent versions of DrRacket, changing tabs pops up an offer to save. But what happens if the file on disk has changed since the file was last saved? In this case (it appears to me) you get a dialog that you can't cancel... Specifically, the dialog says "The file has been modified since it was last saved. Overwrite the modifications?" When you click "cancel", because you don't want to save the modifications... it just pops up the same dialog again.

This is kind of like Matthew's undergraduate joke dialog with the moving "cancel" button, but it's not a joke.

Of course, the easy workaround is to go to another window and make a copy of the file before choosing "overwrite."

Apologies if this has already been fixed; I'm running

Welcome to DrRacket, version 7.7.0.6--2020-05-25(-/f) [cs].

[sorawee]

I'm using 7.7.0.7--2020-06-10(2768499/a) and can confirm that the problem still exists.

[rfindler]

Okay, I see what's happening: you give drracket the focus and so it checks to see if any tabs need saving (because that's one of the times it does that in the mode that you're in) and it discovers that it wants to talk to you. So it opens a dialog (in this case to ask you "really want to save?") and you say "no", at which point the window with the dirty tab gets the focus again and that kicks off another round of drracket getting the focus and trying to save again.

It might be nice if DrRacket could avoid kicking off that second round of asks (as there might be many dirty tabs, theoretically (although hard to achieve in practice if you have this preference turned on)), by noticing that it was getting the focus because it just closed one of its own dialogs. I think I can make that happen, although it doesn't seem straightforward and so I'm not 100% sure I can do that in a reasonable way, and that approach just makes me nervous.

Also this is generally going to be a very fragile state; when you are asking drracket to save a lot on your behalf and you are also asking drracket not to save.

Maybe the right thing is, when you are in the "autosave" (what macos calls "autosave") mode, and there is a reason that saving might be bad, instead of asking about it, drracket simply won't do the save. So the buffer stays dirty (eg if there is an error on a save attempt we don't tell you about it, we just don't save, ditto for this one). And you find out why it stayed dirty when you explicitly save, instead of implicitly save.

I could achieve this effect by having a parameter that signal'd that we're not doing a regular save, we're doing an automatic save and the code in all of the can-save-file? methods will have to just know to consult this parameter and just return #f instead of opening a dialog to ask. Seems easy enough for the framework and perhaps documentation will suffice for any tools that might use can-save-file?.

[rfindler]

Looks natural to me to re-using the existing autosave support for this purpose too (since, in principle, strange things can happen (and have happened in the past if my memory isn't wrong) when the old-school autosave (the thing that writes the file to the disk automatically in its own place when the buffer has been dirty for a while and then deletes it when the file is saved) kicks in).