Since full escaped backup paths can become longer than the maximum filename size
and hashed filenames cannot be restored it is helpful to have a lookup file for
the user to resolve the hashed path.
This is a feature found in vim and commonly used
by Linux kernel test robots to give context about
warnings and/or failures.
e.g. vim +/imem_size +623 drivers/net/ipa/ipa_mem.c
The order in which the commands appear in the args
determines in which order the "goto line:column"
and search will be executed.
As pointed out by @niten94, empty lines in the man page are not just
unnecessary but also cause extra empty lines to be displayed with
alternative `man` implementations, e.g. `mandoc`. To test on Debian,
for example, mandoc's implementation is named `mman` and included in the
`mandoc` package.
* Add syntax highlighting for meson build system
It is basically a port of upstream syntax highlighting for vim,
but a bit less noisy (e.g numbers are not colored).
* meson.yaml: fix meson_options.txt detection
* meson.yaml: remove empty rules
* meson.yaml: add highlighting for operators and brackets
* meson.yaml: rearrange the keywords to be in alphabetical order
* meson.yaml: add highlighting for numbers
Using notrunc will stop the overall truncation of the target file done by sudo.
We need to do this because dd, like other coreutils, already truncates the file
on open(). In case we can't store the backup file afterwards we would end up in
a truncated file for which the user has no write permission by default.
Instead we use a second call of `dd` to perform the necessary truncation
on the command line.
With the fsync option we force the dd process to synchronize the written file
to the underlying device.
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.
