File names starting with periods are perfectly acceptable on Windows
file systems. The only place where this is not acceptable is on
MS-DOS FAT file systems which only support 8.3 file names.
See here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
Since Neovim does not support MS-DOS or 8.3 file names (#605)
we can drop this codepath.
It was not compiling anyways since we do not define WIN3264.
@equalsraf: I took a look at the Vim source pstrcmp() is actually used in the
dos_expandpath(misc1.c). The only difference between the UNIX and WIN32 version
of the functions is the _cdecl call convention annotation - the body of the
function is identical. Neovim kept the comment from the Unix function but not
from the Windows variant. Seems to me its safe to use the same function for
both - and just correct the comment.
If nvim is built from a non-tagged commit, the truncated commit hash is
already appended to the main version string (e.g., "NVIM v0.1.0-83-g959f260 ..."),
making the "Commit:" field redundant.
Regarding the truncated hash length: we don't have nearly enough commits
to worry about collisions, and probably won't ever, so the default
length should be fine.
Problem: The default conceal character is documented to be a space but it's
initially a dash. (Christian Brabandt)
Solution: Make the intial value a space.
4a42710695
Problem: Test fails when the autochdir feature is not available. Test
output contains the test script.
Solution: Check for the autochdir feature. (Kazunobu Kuriyama) Only write
the relevant test output.
d113a80c77
Problem: It is not possible for a plugin to adjust to a changed setting.
Solution: Add the OptionSet autocommand event. (Christian Brabandt)
537443018d
Regarding the individual items in the header:
`Vim - Vi improved by Bram Moolenar`
Bram Moolenar is already mentioned throughout the documentation, as
well as the intro screen.
`:help uganda`
It's already shown to all users who don't use `shortmess+=I` upon
starting nvim, and is already placed prominently in help.txt, i.e.,
`:help` run with no arguments.
`:help credits`
Already mentioned near the top of help.txt.
`README.md`
Already mentioned in develop.txt.
In Windows we can't assume errno will be set by calls to os_* functions,
instead the return value from os_* functions can be used. This commit fixes two
occurences for os_open().
1. EFBIG is replaced with UV_EFBIG and checked against the return from os_open().
2. EOVERFLOW does not have a corresponding libuv constant, and is not defined
by open() in Windows - disabled this case with a UNIX guard, and check the return
value against -EOVERFLOW (libuv errors are negative errno values in Unix).
From #3473, shada.c used errno constants (e.g. ENOENT) to check the return
of os_open(), but in Windows the return from libuv functions is not -errno.
Instead use libuv error constants (e.g UV_ENOENT) for error checks.
Previously os_getperms() returned -1 for any error condition, it
now returns the libuv error code (as returned by os_stat()). This
allows checking for error conditions without relying on errno
(which not available in Windows).
The only case where the errno value from os_getperms() was being used
was in readfile() to set the new-file flag - replaced the errno check
with UV_ENOENT.
Instead of returning bool from os_stat return the actual libuv return code.
This function is static and used internally in nvim/os/fs.c it should not
impact the rest of the API. This is a first step to change other fs functions.
In windows libuv does not return -errno, instead it uses negative
error codes e.g. UV_ENOENT. This commit changes the comments in os_*
functions to reflect this.
