Ooh, more importantly than running in parallel, this actually fixes
error handling. I had chmodded a file to be read-only for testing,
and this is failing on it loudly instead of silently ignoring an error
that I didn't know about! Because it was silenced! That was a bit of a
redundant way of saying that, but better to be heard than be SILENT...!
*crickets*
The backup of the current file will be deleted just after opening it.
I should probably actually prevent that, but this commit just fixes
an error message thrown up when trying to then open another file.
It said "File not found", but confusingly was not referring to the file
you were trying to open, but rather the currently open file.
Repro test steps:
Open a file (optional), make changes, and wait for backup to be saved;
open the new .ans~ backup file (discarding changes to the main file),
then try to open any file. "File not found" message should not be shown.
- This is shorter/cleaner.
- This is less prone to mistaken parentheses placement, although it
should give a type error to do `Static() + Static()`
- I already disabled markup parsing for two cases where filenames are
interpolated, but there was still:
"An unexpected error occurred while reading %1"
which was liable to misinterpret things as markup.
Note that anything in square brackets can be treated as markup and
become hidden, not just recognized tags like [red].
For example, in the Open dialog, typing a filename that doesn't exist,
and then hitting enter, it's supposed to say "File not found", but
if the event isn't prevented/stopped, it will also be handled by
the new dialog, and you won't even see it.
I think the `if self._selected_file_path is None: return` was from
copying from CharacterSelectorDialogWindow and isn't applicable.
(I renamed anything with "character" to "file_path".)
After removing this check, I shouldn't need `or ""` for the Open dialogs
- This fixes a potential race condition where it could auto-save
to the wrong backup file while the file_path was temporarily
set to the path attempting to be written to,
overwriting the backup if it existed, and leaving it behind on close,
since the file_path would be reverted momentarily.
- save_as() no longer uses save(), so save doesn't need a from_save_as
parameter to change the error dialog titles, and there's no more
conceptual awkwardness due to the fact that each function could call
the other.
- discard_backup() no longer needs an optional parameter, because
we no longer discard a backup that isn't associated to the current
document's file_path.
- The "correct thing" is now obvious enough that I don't feel the need
for the "Don't discard the backup until..." comment.
(And of course all that todo junk can go, although the Copy To bit
remains to do.)
It's nice when things Actually Get Simpler!
"Auto-save" can mean saving the actual document you're editing;
in this case it means saving a temporary backup file.
I might even want to introduce auto-saving of the main file later on.
- Recover from backup file if it exists for the document when loading
a document via the CLI or TUI, or if it exists for Untitled when
creating a new document.
- Reorganize CLI arguments handling into passive and active,
so that the active recovery step can use the passive* backup folder
option. (*Directories are created if they don't exist.)
Working on automatically recovering the document,
I'm realizing this is more complicated than I thought.
Consider two instances of the app (A and B) editing the same file:
- Make changes in A
- Open same file in B
- A auto-saves after timer
- Close B
- B deletes auto-save when closing
- A doesn't re-create the auto-save unless further changes are made to
the document, because of the undo tracking, which is basically an
optimization to avoid writing to the disk all day while idle.
Also, there could be a race condition where it saves over the auto save
before recovering it — potentially — like if the auto save interval
was implemented such that it made an immediate call at the start, or
if some other app code tries to auto save initially.
Or, consider if you:
- Make changes in A
- Open same file in B
- Make changes in B, maybe before it detects the backup file if the disk
is very slow for some reason, or if you just ignore the prompt.
(None of the prompts are modal, currently.)
To address these issues, I could add a flag that says whether the
auto save was written, and thus owned by, this session, and make it
not write to a backup file that it didn't create in the current session.
But it still ideally would auto save, just to a different file,
so I could instead have a map of file paths to bools saying whether it's
owned by the app or not and then have a number incremented in the
filename (maybe like `.ans~` and then `.ans~SESSION2~`, including
"SESSION" so it's clear it's not time-based), adding 1 until it's a file
that can be owned by the session when auto saving.
But if an earlier-numbered session closes, you wouldn't want it to leave
a file behind. Either it should delete/rename its backup file to the
earlier number and start saving to that, or it should keep the existing
higher number. I guess if looks at the map first, before checking the
file system, it shouldn't be a problem. It should keep using the higher
number. Would this be a little overkill? Eh, maybe.
