Regarding |script-here|: despite being a language agnostic piece of
advice, it was in `if_perl.txt`. Regardless, we now only have one
support for one legacy plugin interface, so put it in `if_pyth.txt`
Rubycomplete requires 'if_ruby', which has never been in Neovim. Because
of this, remove some mentions of it from the docs, but keep the actual
plugin untouched (as to avoid unneeded maintainence costs). It has a
call to `has('ruby')`, so it will still fall back to syntax completion.
Fixes the handling of the initial input lines of a test script by simply
skipping all initial empty lines.
Helped-by: Florian Walch <florian@fwalch.com>
Suggested-by: Florian Walch <florian@fwalch.com>
Reported by @fourjay, a codepath that causes event_poll() to run before
event_init() will trigger a segfault as the events list will not have
been initialized. Exiting immediately from event_init() causes nvim to
hang, so just exit before running the events.
fixes#2339
Resolves#1753.
https://code.google.com/p/vim/source/detail?r=v7-4-399
Reviewed-by: Felipe Oliveira Carvalho <felipekde@gmail.com>
Helped-by: David Bürgin <676c7473@gmail.com>
Helped-by: Scott Prager <splinterofchaos@gmail.com>
Helped-by: Michael Reed <m.reed@mykolab.com>
Helped-by: Felipe Oliveira Carvalho <felipekde@gmail.com>
event_poll() always leaves the libuv I/O loop after one iteration. The
duration for how long the loop polls for I/O is given by the shortest
timeout of all active timers. Is no timer active, I/O is/could be polled
indefinitely.
To make sure our timer is still active when I/O polling begins,
a prepare handle is used to start the timer right before the polling.
But by only using a timer that restarts after its timeout was reached,
we also can assure that polling is done with (nearly) the same finite
timeout.
For a short explanation how the I/O loop is working, see
http://docs.libuv.org/en/latest/design.html#the-i-o-loop.
Problem : Dereference of null pointer @ 1769.
Diagnostic : Real issue.
Rationale : It seems buffer could be null. Not sure, though.
Resolution : Check for buffer null.
This resolution was chosen as it will always work.
But it could be that buffer can't really be null at that
point. autocmd_win is ruled out by close_window, so that
can't be the case. I'm not sure if other windows without
buffers are possible, so leaving it this way.
If it's confirmed buffer can't be null, resolution through
an assert would be possible and this would be FP, not RI.
Problem : Dead initialization @ 1119.
Diagnostic : Real issue.
Rationale : `obj` is immediately assigned another value through
GET_CONFIG_VALUE macro.
Resolution : Don't initialize.
Helped-by: oni-link <knil.ino@gmail.com>
Problem : Dead initialization @ 1109.
Diagnostic : Real issue.
Rationale : `obj` is immediately assigned another value through
GET_CONFIG_VALUE macro.
Resolution : Don't initialize.
Helped-by: oni-link <knil.ino@gmail.com>
Problem : Dereference of null pointer @ 1053.
Diagnostic : Real issue.
Rationale : Branch "Exiting focused terminal" can actually be executed
when term is NULL.
Resolution : Guard branch with term check.
Problem : Use-after-free @ 15081.
Diagnostic : Multithreading issue.
Rationale : `get_dict_callback` can return NULL on two different
cases: 1) when the dict doesn't contain the given key;
this case is not considered an error. 2) when the key
exists but there's some problem with its value; this is
considered an error.
Then, code calling `get_dict_callback` in
`common_job_callbacks`, as well as code calling
`common_job_callbacks`, uses `did_emsg` to distinguish
between error/non-error cases.
Suggested error path presumes an error condition within
`common_job_callbacks`, with `did_emsg` being true, but
then being false just after returning to calling code in
`f_termopen`.
That, clearly, could only happen if another thread run in
between those points.
Resolution : Refactor `get_dict_callback` and `common_job_callbacks`, so
that they clearly distinguish between error/non-error
situations, without recurring to globals.
Problem : Dereference of null pointer @ 10812.
Diagnostic : False positive.
Rationale : `args->lv_first` can't be NULL, as we have just stated
above that that there's at least one item.
Resolution : Assert.
The fallowing test (reduced), submitted by @mhinz may free term->buf,
leaving the pointer dangling.
```vim
let s:buf = -1
function! s:exit_handler()
execute 'bdelete!' s:buf
endfunction
vnew
let s:buf = bufnr('%')
let id = termopen('sleep 1', { 'on_exit': function('s:exit_handler') })
call s:test()
```
When the buffer is known to be closing, set term->buf to NULL, and check
buf_valid() in on_refresh().
Helped-by: Marco Hinz (@mhinz)
Problem: A search with end offset gets stuck at end of file. (Gary Johnson)
Solution: When a search doesn't move the cursor repeat it with a higher
count. (Christian Brabandt)
https://github.com/vim/vim/releases/tag/v7-4-636
The original fix 3db0a40d69
does not work for more than one loop iteration, because memory allocated
in the previous iteration could be reused in the current iteration.
Because expand_wildcards() never reads the variables *num_file
and *file before the first assignment to them, the initial
values for these variables can be anything. So instead of
calling expand_shellcmd() with *file = "" we set *file = NULL.
That should help coverity see, that not a array-typed value
is freed.
Helped-by: Eliseo Martínez <eliseomarmol@gmail.com>
