| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Also rename underlying C code.
|
|
The new code is preferable because it works independently of the
variable type. Whereas before a change in type, but not within the
sizeof expression would cause a wrongly sized allocation.
|
|
|
|
s/Action/Revision/g
|
|
|
|
|
|
|
|
|
|
The default atomic save method using rename(2) would correctly fail,
but the calling code would wrongly assume it was because of dealing
with a special (e.g. hard or symlink) file or that some other properties
(e.g. POSIX ACL, SELinux labels, permissions etc) could not be restored.
It would then go on to ftruncate(2) the file, if the following writes
then fail (which is likely if the new file content is bigger or some
other process has used up disk space in the mean time) we lose data.
This should fix it for the common case i.e. regular file where the
rename(2) based method is used. The problem persits when directly
overwriting a file.
It is unclear whether this could be improved/fixed by:
1) first appending the new file content to the old one
2) fsync the data (old||new)
3) deleteing the original file content by overwritting it with
the previously appended new file content. That is essentially
moving the new file content from the end of the file to the start.
4) ftruncate to the new file size
5) fsync the data (new)
if during 1) or 2) an error would occur we could revert the operation
by doing a ftruncate to the original file size. An error in steps 3-5
would still be fatal.
Another option would be to first write a backup file somewhere.
|
|
|
|
Heap allocates a zero terminated string of the given range.
Freeing is the caller's responsibility.
Checks for unsigned integer overflow i.e. passing SIZE_MAX
as len will always fail because there is no room for the
terminating NUL byte. This is important as EPOS is defined
to be SIZE_MAX.
|
|
|
|
|
|
|
|
They currently consider any character for which wcwidth(3)
return 0 as a combining character.
|
|
At the start of text_save_range we stat(2) the file to check whether
we have currently mmap(2)-ed it. Then we proceed to write the new
file content which changes modification time. Hence we have to
stat(2) again to retrieve it.
This should fix spurious warnings about file changes outside the
editor when editing e.g. symlinked files.
|
|
|
|
This affects the cursor placement when redoing changes in
single cursor mode.
Closes #42
|
|
|
|
Closes #76
|
|
Convenient way to insert formated data into a Text.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we use the file / virtual memory system as cache (using mmap(2))
and another process truncates the file we are editing, we have a
problem. All we can do is catch the resulting SIGBUS, close the
corresponding window and print a warning message.
To test this use:
$ dd if=/dev/zero of=TEST bs=8M count=1
$ vis TEST
:! echo TRUNCATE > TEST
|
|
Eventually this should probably be rewritten to use an iternal
regex engine, currently it has unacceptable memory usage, it
copies the whole text.
|
|
|
|
|
|
Set umask before calling mkstemp. According to POSIX 2008 this is
not necessary since the temporary file is guaranteed to be created
with permission restricted to the current user. However this is
more secure on non-conforming systems and safe as long as we do not
use multiple threads.
Fixes Coverity CID 101333.
|
|
|
|
|
|
|
|
|
|
Also apply syntax rules every time the file name changes.
|
|
Files smaller than 8M are now copied into an internal buffer
upon load. Thus they can be safely truncated. Larger files are
memory mapped and use the file/virtual memory system as caching
layer. Hence truncating them will corrupt the file content.
Eventually the resulting SIGBUS should be handled gracefully.
|
|
Try to do an atomic save using rename(2) unless
* the file is a symbolic link
* the file is a hard link
* file ownership can not be preserved
* file group can not be preserved
* POSXI ACL can not be preserved (if enabled)
* SELinux security context can not be preserved (if enabled)
in which case the file is overwritten in place. However a failure
to do so results in data loss.
Closes #47.
|
|
|
|
Since text_range_write is called several times in cmd_filter, the undo
command does not undo the whole filter operation but only up to the
last call of text_range_write. Removing the snapshot-taking code solves
this issue.
|
|
Instead use the text-dump git branch if necessary.
|
|
This really needs some unit tests.
|
|
|
|
|
|
Currently the following arguments are accepted:
{count} Go to older text state {count} times.
{N}s Go to older text state about {N} seconds before.
{N}m Go to older text state about {N} minutes before.
{N}h Go to older text state about {N} hours before.
{N}d Go to older text state about {N} days before
|
|
|
|
|
|
|
|
|
