Since pty events are queued, it is possible that the reads will be reordered.
Example scenario:
In the terminal you have output combined from stdout and stderr. A program
generates output, first you have some output on stdout, then output on stderr,
output on stdout, output on stderr,... The whole output should be interleaved
from both streams.
Each output generates a read_event and they are placed in the same queue. If the
queue is processed, the first read_event will send the whole stdout output to
the terminal (on_job_output() consumes the whole buffer). The next read_event is
similar for stderr. The remaining read events do nothing because now both
RBuffer are already empty. So the terminal would show first the stdout output
and after that the stderr output.
This commit fixes the problem by disabling stderr stream in pty processes.
That's ok because they all represent the same stream(duplicate file
descriptors), plus one stream is simpler to deal with.
- Improve the implementation of deferred/immediate events.
- Use the new queue module to change how/when events are queued/processed by
giving a private queue to each emitter.
- Immediate events(which only exist to break uv_run recursion) are now
represented in the `loop->fast_events` queue.
- Events pushed to child queues are propagated to the event loop main queue and
processed as K_EVENT keys.
API functions exposed via msgpack-rpc now fall into two categories:
- async functions, which are executed as soon as the request is parsed
- sync functions, which are invoked in nvim main loop when processing the
`K_EVENT special key
Only a few functions which can be safely executed in any context are marked as
async.
out_data_cb() can return without emptying the full RBuffer (no NL was
seen). Because the shell output stream is stopped until space in the
Rbuffer is freed up, no more shell output is written.
To prevent this, output the full RBuffer when write_output() did not
write anything.
write_output() can also process the same RBuffer content more than once,
if no NL was seen. To prevent NUL bytes from producing new lines (if
lines are not written to a buffer), translate NUL to SOH(1).
Fixes#2983
parse_msgpack() closes a channel's stream on EOF error and the stream's
close callback close_cb() is queued for the next libuv loop iteration.
When parse_msgpack() returns, it has freed the channel and the queued
stream callback will access this freed memory.
To prevent this, increase the channel's reference count and let the
stream's close callback call decref().
Fixes#3128
os_get_user_name() requires getuid(), which is only available in UNIX. Return
FAIL for non UNIX systems.
On FAIL os_get_user_name() fills the buffer with the uid. In Windows libuv
uses 0 for uid in stat structs, so 0 is used here too.
Compiler warning was found in [QuickBuild logs][1] from [this page][2]. GCC and
clang on travis appear to be fine. Relevant log parts:
Step Log (master>buildall>build-node?testNode=linux-64>build-and-run-tests>build-and-run-tests-parameterized?buildType=Release>configure-neovim-and-build-nvim)
<…>
16:26:31,364 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/eval.c: In function ‘f_msgpackdump’:
16:26:31,364 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/eval.c:12371:26: error: ‘cur_tv’ may be used uninitialized in this function [-Werror=uninitialized]
16:26:31,364 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/eval.c:12328:21: note: ‘cur_tv’ was declared here
16:26:31,938 WARN - cc1: all warnings being treated as errors
[1]: http://neovim-qb.szakmeister.net/wicket/page?4-1.ILinkListener-content-buildTab-panel-errorContainer-steps-5-logLink
[2]: http://neovim-qb.szakmeister.net/build/2099/overview
This is a port of my original contribution to Vim, added in 7.4.687
(https://github.com/vim/vim/commit/v7-4-687). The TUI code has been
heavily refactored (see esp. 25ceadab37),
so this required some translation, but the logic is the same.
Currently, there are two functions in the UI API that are called when
the mode changes: insert_mode() and normal_mode(). These can be folded
into a single mode_change() entrypoint which can do whatever it wants
based on the mode it is passed, limited to INSERT and NORMAL for now.
The python-client has it's own test suite, and this isn't even run: see
the has('nvim') call.
Taken from
1acf4ace52
with minor modifications.
"Now that you've done the necessary cleanup, why not go ahead and merge
this." @bfredl
A menu item can have separate bindings for each Vim mode.
:emenu checks to see which binding it should execute. But, it assumes
it can only be called from Normal mode, so its mode detection is based
on some guesswork. For instance, it detects if you've just used C-O
and, if so, uses the Insert mode binding.
Now that :emenu can be called from any mode (via vim_command), this
commit has it check the actual mode we're in, and simply use the
binding for that mode if we aren't in Normal mode.
Neither setting the 'columns' and 'lines' options nor using the
`:winsize` command resized the terminal window, which caused display
glitches.
Re: #2863
The test is also split in several blocks and heavily modernized. This was
done to prevent the following quoting and escaping problems during migration:
- the vim command `put =...` treats double quotes as the start of a comment so
they have to be escaped with a backslash
- when inserting control characters on the command line they have to be
escaped with <C-V>
The parts one and two of the test are functional identical so they are wrapped
in a local function. The only difference was which letters where used to test
the same feature.
Part six did test a flag in 'cpoptions' that has been removed in neovim. It
has therefore been removed as well.
Reviewed-by: Michael Reed <Pyrohh@users.noreply.github.com>
There are more terminals which have bracketed paste support and it
doesnt seem to do any harm with terminals that dont support it eg screen
Reviewed-by: Marco Hinz <mh.codebro@gmail.com>
Reviewed-by: Michael Reed <Pyrohh@users.noreply.github.com>
"+1 Let's see what happens" Justin M. Keyes <justinkz@gmail.com>
glibc on i386 seems to have an optimization that makes it harder to call
some math functions indirectly from inside an inlined function, causing
compile-time errors with some versions of gcc. This removes inlining on
that platform.
Closes#3071
