while there is some controversy, stdpath('cache') looks like a better fit for logs than stdpath('data'): you can remove logs without preventing nvim to work which fits the XDG_CACHE_HOME definition of `user specific non-essential data files`.
vim-patch:8.2.1757: Mac: default locale is lacking the encoding
Problem: Mac: default locale is lacking the encoding.
Solution: Add ".UTF-8 to the locale. (Yee Cheng Chin, closesvim/vim#7022)
a5fe91e6dc
Cherry-pick test_environ.vim changes from patch 8.2.1432.
Seems like redundant env var separators (";" on Windows) in $PATH can
cause weird behavior. From #7377:
> After some time, system(['win32yank', '-o']) and system('win32yank -o')
> start returning different results: specifically first returns an
> empty string.
>
> 1. $PATH weirdly contains double semicolon followed by path to the
> “installation directory” (unpacked directory from archive).
> 2. If I run `let $PATH=substitute($PATH, ';;', ';', 'g')` the problem is fixed.
close#7377
ref 224f99b85d
- remove redundant autocmd list
This "grouped" list is useless, it only gets in the way when searching
for event names.
- intro.txt: cleanup
- starting.txt: update, revisit
- doc: `:help bisect`
- mbyte.txt: update aliases 1656367b90. closes#11960
- options: remove 'guifontset'. Why:
- It is complicated and is used by almost no one.
- It is unlikely to be implemented by Nvim GUIs (complicated to parse,
specific to Xorg...).
Problem: MS-Windows: E325 message may use incorrect date format.
Solution: Convert strftime() result to 'encoding'. Also make the message
translatable. (Ken Takata, closesvim/vim#4685, closesvim/vim#4681)
663bbc09ba
The libcall family of functions need to use "int" for both input and
output. The output side was fixed in 9c42232 but I forgot about the
input side.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch libcallnr
# Your branch is up to date with 'upstream/master'.
#
# Changes to be committed:
# modified: src/nvim/eval/funcs.c
# modified: src/nvim/os/dl.c
#
Zero out the caller's FileInfo in all the functions which populate the
struct. The contents are considered private, so we need to ensure
it's initialized.
If the stat call fails, the buffer we get back from libuv may not have
any valid data in it, so don't copy it into the caller's FileInfo.
This was happening, expectedly, in functional/ex_cmds/write_spec.lua's
"write errors out correctly", which caused it to fail in certain
environments:
test/functional/ex_cmds/write_spec.lua:130: Expected objects to be the same.
Passed in:
(string) 'Vim(write):E212: Can't open file for writing: not a directory'
Expected:
(string) 'Vim(write):E166: Can't open linked file for writing'
Problem: Too many #ifdefs.
Solution: Graduate the +autocmd feature. Takes away 450 #ifdefs and
increases code size of tiny Vim by only 40 Kbyte.
f2bd8ef2b4
Change resolve() to resolve symbolic links on Windows
Neovim worked the same way as vim for shortcuts, but didn't handle symbolic links and junction cases. This PR implements the same behavior for symbolic links and junctions as for vim.
Vim's documentation simply states that libcallnr() should be used "for a
function that returns an int". Based on the tests, code, and common
syscall interfaces, this should likely be taken literally instead of
trying to apply some well-defined type lipstick.
Notably, this change fixes Test_libcall_libcallnr on hppa (a 32-bit
big-endian system).
