vim-patch:fafcf0dd59fd
patch 8.0.1206: no autocmd for entering or leaving the command line
Problem: No autocmd for entering or leaving the command line.
Solution: Add CmdlineEnter and CmdlineLeave.
fafcf0dd59
The hardcoded URL breaks very often, this confuses people.
Instead, auto-detect if no URL is provided.
Also auto-detect if the script is invoked with no arguments.
When building in release mode, gcc generated a maybe-initialized
warning in get_syn_options. The warning is both right and wrong;
there is an execution path where the len variable is not
initialized in the code:
...
int len;
...
for (fidx = ARRAY_SIZE(flagtab); --fidx >= 0; ) {
p = flagtab[fidx].name;
int i;
for (i = 0, len = 0; p[i] != NUL; i += 2, ++len)
if (arg[len] != p[i] && arg[len] != p[i + 1])
break;
// <snip>
}
...
arg = skipwhite(arg + len);
...
The initial for loop will not execute if ARRAY_SIZE(flagtab) == 0,
and thus len will never be initialized. flagtab is a local-static
variable, initialized to a long array of structured data, so
ARRAY_SIZE(flagtab) can't be 0.
However, gcc doesn't recognize ARRAY_SIZE(flagtab) as a constant.
There are any number of reasons this could happen. In any case,
the message can be fixed with a len=0 before the first for loop.
In addition to the above warning, I've labeled flagtab and
first_letters as const. They should never change.
closes#7599
Helped-by: oni-link <knil.ino@gmail.com>
Freeing `dirname` was first introduced by a code refactoring from `ex_helptags()` to `do_helptags()` (`vim-patch:7.4.1551`)(#4648) and later removed by `vim-patch:7.4.1562`(#4660).
Only problem with that is, that the patches were not applied in order so the fixing patch was declared `N/A`.
So `do_helptags()` should have never freed `dirname`.
Problem: Cannot access the arguments of the current function in debug mode.
(Luc Hermitte)
Solution: use get_funccal(). (Lemonboy, closesvim/vim#1432, closesvim/vim#1352)
c7d9eacefa
When compiling with CMAKE_BUILD_TYPE=RelWithDebInfo, several
-Wmaybe-uninitialized warnings are printed. These were thought to
be false positives (#5061); there are no control paths that lead
to an uninitialized value. However, when gcc is run in -O2 mode,
it makes a mistake while generating the necessary logic.
Specifically, for the code:
...
int = 0; // Index of the server whose address equals addr.
for (; i < watchers.ga_len; i++) {
watcher = ((SocketWatcher **)watchers.ga_data)[i];
// <snip>
}
if (i >= watchers.ga_len) {
ELOG("Not listening on %s", addr);
return;
}
...
Gcc generates:
...
<+98>: cmp %ebx, %ebp
<+100>: jg 0x530f13 <server_stop+55>
<+102>: cmp %ebp, ebx
<+104>: jl 0x530f7e <server_stop+162>
...
Normally, the if statement should catch the only control path
where watcher is not assigned: watchers.ga_len <= 0. When
compiled, the assembly lines 98 and 100 correspond to checking if
i < watchers.ga_len, and the lines 102 and 104 correspond to
checking if i >= watchers.ga_len. The assembly seems to compare
ebp (which is watchers.ga_len) with ebx (which is i), and jump
if greater; then do the same comparison and jump if less. This is
where gcc makes a mistake: it flips the order of the cmp
instruction. This means that the REAL behavior is first check if
i < watchers.ga_len and then check if i < watchers.ga_len. Which
means the code inside the if statement is NEVER executed; no
combination of i and watchers.ga_len will ever trigger ELOG().
So not only is this a use of an uninitialized value if
watchers.ga_len == 0 (or technically, if it's less than zero too),
it also clobbers any error detection if the for loop reaches the
last entry (which would normally cause i == watchers.ga_len too).
This commit fixes this issue by adding a bool to keep track of
whether a watcher was found during the loop. This makes gcc
generate the correct code, avoiding both bugs.
Problem: The return value of mode() does not indicate that completion is
active in Replace and Insert mode. (Zhen-Huan (Kenny) Hu)
Solution: Add "c" or "x" for two kinds of completion. (Yegappan Lakshmanan,
closesvim/vim#1397) Test some more modes.
e90858d022
The flag enables the current local directory set by ":lcd" to be saved
to views which is the current default behaviour. The option can be
removed to disable this behaviour.
closes#7435
vim-patch:8.0.1289
neovim-ruby-host is a ruby script.
neovim-node-host is a shell script.
Both don't work in cmd.exe so gem and npm provide batchfile shims.
Return the full path of these shims, cmd.exe knows better what to do with these files.
Make the Windows impl closer to Vim os_win32.c, and the Unix impl closer
to Vim os_unix.c.
Outcomes:
- Do not send negative fd to close(). ref #4806#4772#6860
- Fallback return-value is now correct in (hopefully) all cases.
- unix: check S_ISXXX instead of relying on os_open (which can fail for
irrelevant reasons). buf_write() expects NODE_WRITABLE for character
devices such as /dev/stderr. 96f834a842
Anything claiming to be an xterm gets DECSCUSR. This is the only
reasonable choice unless/until we get more reliable detection (#7490).
ref #6997closes#7550
Fix bug that checked for npm AND yarn, where we wanted npm OR yarn.
But since we call `npm` exclusively, and it's highly unlikely you have
yarn installed without npm, let's just remove the yarn check altogether.
Addresses https://github.com/neovim/node-client/issues/41
Problem: Crash when 'fileformat' is forced to "dos" and the first line in
the file is empty and does not have a CR character.
Solution: Don't check for CR before the start of the buffer.
2aa5f696b9
:checkhealth reports that remote plugins are unregistered
after running :UpdateRemotePlugins because of the backslashes in filepath.
Normalize them to forward slashes because the paths in rplugin.vim are normalized in autoload/remote/host.vim.
* vim-patch:8.0.0245
Problem: The generated zh_CN.cp936.po message file is not encoded properly.
Solution: Instead of using zh_CN.po as input, use zh_CN.UTF-8.po.
16038d50c4
* vim-patch:8.0.0248
Problem: vim_strcat() cannot handle overlapping arguments.
Solution: Use mch_memmove() instead of strcpy(). (Justin M Keyes,
closesvim/vim#1415)
45600ce8f2
Integer is a 64-bit type so using %d can produce incorrect results.
test/functional/api/highlight_spec.lua @ 35: highlight api nvim_get_hl_by_id
...W7Xi/neovim-0.2.1/test/functional/api/highlight_spec.lua:46: Expected objects to be the same.
Passed in:
(string) 'Invalid highlight id: 7671724'
Expected:
(string) 'Invalid highlight id: 30000'
This fixes an apparent difference in behavior between Lua and LuaJIT.
Lua fails to format nil:
test/functional/terminal/tui_spec.lua:381: bad argument #2 to 'format' (string expected, got nil)
Doc for UV_PROCESS_DETACHED in uv.h mentions:
> child process will still keep the parent's event loop alive unless
> the parent process calls uv_unref() on the child's process handle.
ref #3944
Problem: When setting wildoptions=tagfile the completion context is not set
correctly. (desjardins)
Solution: Check for EXPAND_TAGS_LISTFILES. (Christian Brabandt, closesvim/vim#1399)
ba47b51ff8
Problem: Completion of user defined functions is not covered by tests.
Solution: Add tests. Also test various errors of user-defined commands.
(Dominique Pelle, closesvim/vim#1413)
65c836e600
