Closes#6540
In #6221 there was a mistake in calculating which folds need to be
re-ordered. When there are no folds after those that have been adjusted,
then `move_end` remains 0. This results in reverse_fold_order()
swapping folds that have been adjusted with uninitialised folds in the
remainder of the grow array.
Add a check in foldMoveRange() to account for this case.
Calling cmd.exe in Windows follows a very different pattern from Vim.
The primary difference is that Vim does a nested call to cmd.exe, e.g.
the following call in Vim
system('echo a 2>&1')
spawns the following processes
"C:\Program Files (x86)\Vim\vim80\vimrun" -s C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIoC169.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c (echo a 2>&1
>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2>&1)
The escaping with ^ is needed because cmd.exe calls itself and needs to
preserve the special metacharacters for the last call. However in nvim
no nested call is made, system('') spawns a single cmd.exe process.
Setting shellxescape to "" disables escaping with ^.
The previous default for shellxquote=( wrapped any command in
parenthesis, in Vim this is more meaningful due to the use of tempfiles
to store the output and redirection (also see &shellquote). There is
a slight benefit in having the default be empty because some expressions
that run in console will not run within parens e.g. due to unbalanced
double quotes
system('echo "a b')
Disable CommandLineToArgvW-standard quoting for cmd.exe.
libuv assumes spawned processes follow the convention expected by
CommandLineToArgvW(). But cmd.exe is non-conformant, so for cmd.exe:
- With system([]), the caller has full control (and responsibility) to
quote arguments correctly.
- With system(''), shell* options are used.
libuv quoting is disabled if argv[0] is:
- cmd.exe
- cmd
- $COMSPEC resolving to a path with filename cmd.exe
Closes#6329
References #6387
Reasoning is majorly the same: check whether lua has bug or API function has
bug, but on the other side: previous commit is checking whether similar bug when
using API via msgpack RPC, this commit is checking whether another API function
used via lua bindings triggers the same bug. Should additionally give a hint
about which lua code contains a bug.
Lua has too many pitfalls here:
- os.execute() requires shell-escaping
- os.execute() has breaking changes between Lua 5.1 and 5.2
- No native way in Lua to handle "readonly" etc. on Windows
Before this commit it emitted e_spell_trunc in the first case and
treated file as completely valid on the second. While first is fine
(both errors are actually valid, though old error is probably better),
second results in incorrect regex used.
It looks like Neovim has a bug: if `startinsert` is called using `command()`
then `-- TERMINAL --` gets replaced with `-- --` (and also a cursor appears).
