| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
As currently implemented this does not properly integrate with
multiple cursor support. The functionality should be provided
in a layer higher up.
The jumplist and changelist need to be redesigned, for now they
are broken.
|
|
|
|
This is no longer needed because we always insert \n never \r\n.
|
|
|
|
Add casts to uintptr_t to avoid unrelated pointer comparisons.
|
|
|
|
Fix #536
|
|
|
|
Use something like dos2unix(1) and unix2dos(1), if you
need to edit such files.
|
|
|
|
These are generally implemented efficiently in libc.
While memrchr(3) is non-standard, it is a common extension.
If it is not available, we use a simple C implementation from musl.
|
|
|
|
|
|
At some point we might drop this mess and ask users to rely
upon dos2unix(1) and unix2dos(1), respectively.
|
|
vsnprintf fails
|
|
This was wrongly changed in commit 74085e92c095d0bf4b98e262cc07ccf9b7dfff3b.
|
|
If the user wants new files to be created as 600, they will have set
their umask to 077 in their environment. vis shouldn't restrict this
further than the user has configured.
|
|
POSIX says that
The mkstemp() function shall use the resulting pathname to create the
file, and obtain a file descriptor for it, as if by a call to:
open(pathname, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR)
So this umask change didn't do anything in practice, unless the original
umask was more restrictive than 0177.
|
|
|
|
|
|
Change the text_iterator_char_{prev,next} functions to treat
them as a single character, meaning cursor motions will skip
both bytes at the same time.
|
|
|
|
|
|
We now guarantee the existence of at least one non-sentinel
piece at all time and allow iterators to recover from these
delimiting pieces.
|
|
Unlike EOF address 0 needs no special treatment.
|
|
Handle zero length pieces gracefully. At some point
we should write a comprehensive set of unit tests
for the iterator API.
|
|
|
|
Technically this macro name is in the reserved namespace of errno.h.
The same is true for EPOS. Maybe we should rename them at some point,
but for now the short names are convenient.
Fix #443
Close #444
|
|
This should avoid undefined pointer comparisons.
|
|
This will be used for unit test purposes to force more allocations.
|
|
Work around for a (bogus?) tis-interpreter warning.
|
|
|
|
There are cases where it is useful to specify how the file should be saved.
|
|
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.
|
|
|
