before, calling vim.schedule() from inside an event would execute
the scheduled callback immediately after this event without
checking for user input in between. Break event processing
whenever user input or an interrupt is available.
Before #12937, the only way to specify the `$TERM` for a pty job was
through the `TERM` key in the job's opts dict. This was shuttled to the
child process throug a special field on the PtyProcess object and
injected into the environment after forking.
Now that we have a proper way to specify the environment for a job, we
can simply ensure that the env dict has a proper `TERM` set and avoid
the extra shuttling of data around.
This deprecates the use of the `TERM` option, but will still honor it if
present, although at a lower priority than a `TERM` present in the env
dict.
This also fixes#13874 because we're no longer trying to overwrite
`TERM` in the env dict with the special pty `term_name`. Doing so
raises an internal error because of the existing key which, under
certain circumstances, would cause the "hit enter" prompt. However,
since the child process had already forked, there was no way for the
user to acknowledge the prompt and we would just hang there.
assert() is compiled out for release builds, but we don't want to
continue running in these impossible situations.
This also resolves the "implicit fallthrough" warnings for the asserts
in switch cases.
Binding _NSGetEnviron()'s return value to a local variable and then
re-binding that is incorrect. We need to directly update what
_NSGetEnviron() refers to.
When starting a pty job, there are certain env vars that we need to
either add or remove. Currently, there are two relevant scenarios.
* Removing irrelevant env vars on Unix, mostly related to the terminal
hosting nvim since they do not apply to a libvterm-hosted terminal.
* Adding required env vars for Windows jobs.
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.
