When writing a backup file, we should write it atomically (i.e. use a
temporary file + rename) in all cases, not only when replacing an
existing backup. Just like we do in util.SafeWrite(). Otherwise, if
micro crashes while writing this backup, even if that doesn't result
in corrupting an existing good backup, it still results in creating
an undesired backup with invalid contents.
Use the same backup write helper function for both periodic
background backups and for temporary backups in safeWrite().
Besides just removing code duplication, this brings the advantages
of both together:
- Temporary backups in safeWrite() now use the same atomic mechanism
when replacing an already existing backup. So that if micro crashes
in the middle of writing the backup in safeWrite(), this corrupted
backup will not overwrite a previous good backup.
- Better error handling for periodic backups.
When we need to remove existing backup for whatever reason (e.g. because
we've just successfully saved the file), we should do that regardless of
whether backups are enabled or not, since a backup may exist regardless
(it could have been created before the `backup` option got disabled).
We should cancel previously requested periodic backup (and remove this
backup if it has already been created) not only when saving or closing
the buffer but also in other cases when the buffer's state changes from
modified to unmodified, i.e. when the user undoes all unsaved changes.
Otherwise, if micro terminates abnormally before the buffer is closed,
this backup will not get removed (so next time micro will suggest the
user to recover this file), even though all changes to this file were
successfully saved.
Micro's logic for periodic backup creation is racy and may cause
spurious backups of unmodified buffers, at least for the following
reasons:
1. When a buffer is closed, its backup is removed by the main goroutine,
without any synchronization with the backup/save goroutine which
creates periodic backups in the background.
A part of the problem here is that the main goroutine removes the
backup before setting b.fini to true, not after it, so the
backup/save goroutine may start creating a new backup even after it
has been removed by the main goroutine. But even if we move the
b.RemoveBackup() call after setting b.fini, it will not solve the
problem, since the backup/save goroutine may have already started
creating a new periodic backup just before b.fini was set to true.
2. When a buffer is successfully saved and thus its backup is removed,
if there was a periodic backup for this buffer requested by the main
goroutine but not saved by the backup/save goroutine yet (i.e. this
request is still pending in backupRequestChan), micro doesn't cancel
this pending request, so a backup is unexpectedly saved a couple of
seconds after the file itself was saved.
Although usually this erroneous backup is removed later, when the
buffer is closed. But if micro terminates abnormally and the buffer
is not properly closed, this backup is not removed. Also if this
issue occurs in combination with the race issue #1 described above,
this backup may not be successfully removed either.
So, to fix these issues:
1. Do the backup removal in the backup/save goroutine (at requests from
the main goroutine), not directly in the main goroutine.
2. Make the communication between these goroutines fully synchronous:
2a. Instead of using the buffered channel backupRequestChan as a storage
for pending requests for periodic backups, let the backup/save
goroutine itself store this information, in the requestesBackups
map. Then, backupRequestChan can be made non-buffered.
2b. Make saveRequestChan a non-buffered channel as well. (There was no
point in making it buffered in the first place, actually.) Once both
channels are non-buffered, the backup/save goroutine receives both
backup and save requests from the main goroutine in exactly the same
order as the main goroutine sends them, so we can guarantee that
saving the buffer will cancel the previous pending backup request
for this buffer.
Various methods of Buffer should be rather methods of SharedBuffer. This
commit doesn't move all of them to SharedBuffer yet, only those that
need to be moved to SharedBuffer in order to be able to request creating
or removing backups in other SharedBuffer methods.
Instead of calculating the hash of the buffer every time Modified() is
called, do that every time b.isModified is updated (i.e. every time the
buffer is modified) and set b.isModified value accordingly.
This change means that the hash will be recalculated every time the user
types or deletes a character. But that is what already happens anyway,
since inserting or deleting characters triggers redrawing the display,
in particular redrawing the status line, which triggers Modified() in
order to show the up-to-date modified/unmodified status in the status
line. And with this change, we will be able to check this status
more than once during a single "handle event & redraw" cycle, while
still recalculating the hash only once.
- extract the open logic into `openFile()` and return a `wrappedFile`
- extract the closing logic into `Close()` and make a method of `wrappedFile`
- rename `writeFile()` into `Write()` and make a method of `wrappedFile`
This allows to use the split parts alone while keeping overwriteFile() as simple
interface to use all in a row.
In `ReloadSettings()` the `filetype` can change upon globbed path given by
the `settings.json` or by identifying a different `filetype` based on the
file name given or pattern present inside the file.
To prevent further recursion caused by checking the `filetype` again, its
processing stops here and isn't considered in `DoSetOptionNative()`
once again where the callbacks are usually triggered.
Like in NewBuffer(), we need to update glob-based local settings
before updating the filetype, since the filetype itself may be among those
glob-based local settings.
* `UpdatePathGlobLocals()`
* to apply the settings provided within e.g. "/etc/*": {}
* `UpdateFileTypeLocals()`
* to apply the settings provided within e.g. "ft:shell": {}
We don't need to call `InitLocalSettings()` twice any longer.
In cursor's Goto(), which is currently only used by undo and redo, we
restore remembered LastVisualX and LastWrappedVisualX values. But if
the window had been resized in the meantime, the LastWrappedVisualX
may not be valid anymore. So it may cause the cursor moving to
unexpected locations.
So for simplicity just reset these values on undo or redo, instead of
using remembered ones.
Restore the original meaning of LastVisualX before commit 6d13710d93
("Implement moving cursor up/down within a wrapped line"): last visual x
location of the cursor in a logical line in the buffer, not in a visual
line on the screen (in other words, taking tabs and wide characters into
account, but not taking softwrap into account). And add a separate
LastWrappedVisualX field, similar to LastVisualX but taking softwrap
into account as well.
This allows tracking last x position at the same time for both cases
when we care about softwrap and when we don't care about it. This can be
useful, for example, for implementing cursor up/down movement actions
that always move by logical lines, not by visual lines, even if softwrap
is enabled (in addition to our default CursorUp and CursorDown actions
that move by visual lines).
Also this fixes a minor bug: in InsertTab(), when `tabstospaces` is
enabled and we insert a tab, the amount of inserted spaces depends on
the visual line wrapping (i.e. on the window width), which is probably
not a good idea.
