Tuanglen wrote:Pretending that you have successfully opened a file and inventing contents for it is unacceptable. If you can't open it, don't open it. If it's already opened but you lose contact with the drive it's stored on, you ought to say something about the problem. You don't have to automatically close it, but you shouldn't just pretend that everything is fine.
ST doesn't pretend, it's just not overly verbose about it.
It does log failed file open to the console, but that's not really visible to the user most of the time.
It does put a disk icon next to the file name on the tab which lets the user know that the buffer has changed - which should be an unusual sight if it happens right after you activate that tab (provided you have "save_on_focus_lost" turned on), but maybe sometimes the user can miss it in a hurry.
The fact that the buffer is empty should be a dead giveaway that something is not right most of the time though - normally you should know that wasn't supposed to happen, especially when coupled with that modified state icon. And empty is a logical content for a failed read.
Maybe at this point ST could show a dialog box telling that it failed to read the file, just to be really fool proof, but so far so good.
But if at this point the user switches to another tab or exits ST and in the meantime the file becomes available again, yeah, good bye file when the user activates that tab again.
Because for some reason a "save on focus lost" feature decides to save it on focus gained instead. And then shows the ridiculous dialog "file has changed on disk, ok to reload"... yeah, no shit it has changed, because you just saved empty buffer over it you stupid thing
So this part really must be fixed.
The rest is arguable.
It happens only with "save_on_focus_lost" enabled, only if ST is restarted at least once while the file is unavailable, and only if the buffer is activated. So that's a few necessary ifs for things to go wrong, but still...