If the backing stream for a :terminal was closed (e.g. if the shell exits
unexpectedly) there may be pending input on the loop which will be processed
before the terminal close event (which is queued on the same loop).
terminal_send checks term->closed but this does not reflect the state of the
underlying streams. The terminal.c module in fact has no knowledge of the
streams (this seems intentional: it is abstracted as TerminalOption.write_cb).
The SIGCHLD handler (pty_process_unix.c) is executed immediately, and it
triggers a stream teardown so Stream.closed=false (TerminalJobData.in.closed).
When the pending writes are handled by eval.c:term_write, wstream_write() aborts
because it sees the closed Stream.
To avoid that, this commit checks Stream.closed in eval:term_write() before writing
to the WStream. (As hinted above, we cannot do this in terminal:terminal_send()
because that module cannot inspect the underlying streams.)
References #5445https://github.com/neovim/neovim/pull/5445#issuecomment-252529766
`utf_ambiguous_width` expects the Unicode character, but in 9e1c6596 I
just passed the first UTF-8 byte to the function. This led to various
display problems because now many multi-cell characters weren't falling
into that part of the branch.
Also, to better align with the existing Vim code, remove the forced
cursor update. Setting the flag will cause it to happen in the next
UI_CALL.
Thanks to qvacua for all the help investigating the issue!
Closes#5448
On architectures where `sizeof(long)` != 8, "%" PRId64 will read junk from
memory. This was seen on various Debian builds where
test/functional/legacy/close_count_spec.lua would fail due to `1<C-w>c`
emitting an error like `E488: Trailing characters: close-87944975647104`.
Changing the `Prenum` parameter to int64_t ensures it is safe to use
`"%" PRId64`, and make another small step towards removal of the use of
`long`.
Allowing this to be controlled externally improves reproducibility, as
well as provides a more useful address to report for "Compiled by". For
example, I intend to set it to the packaging list when building the
Debian package.
Signed-off-by: James McCoy <jamessan@jamessan.com>
We use a Makefile which in turn uses cmake. If we wanted to set the install
prefix for cmake, we had to do this so far:
make CMAKE_FLAGS="-DCMAKE_INSTALL_PREFIX=/tmp/nvim"
That's long and hard to remember. Following the conventions of other Makefiles,
this now works as well and is equivalent:
make PREFIX=/tmp/nvim
If multiple versions of a package are installed, the provider health check could
choose a wrong path:
/usr/local/lib/python3.5/site-packages/neovim-0.1.10-py3.5.egg-info/PKG-INFO
/usr/local/lib/python3.5/site-packages/neovim-0.1.9-py3.5.egg-info/PKG-INFO
Prior to this change :CheckHealth could falsely show 0.1.9 as the installed
version, since glob() doesn't enforce any predictable order.
Now we sort all potential paths numerically in descending order and just look at
the first path instead.
unibi_format() calls out() multiple times for a given format string.
When data->buf fills up during this process, flush_buf() gets called,
which possibly calls unibi_out() again to toggle the cursor visibility.
However, if we were halfway through outputting an escape sequence, doing
this will clobber it, resulting in junk being displayed.
Fix this by not toggling the cursor visibility when draining a full
buffer in out().
References #4867
For users who use a "bar" shape in the shell, it's annoying that Nvim starts
with that same cursor shape, despite starting in normal-mode. So default to the
normal-mode "block" shape instead. (Note: technically it's possible some user
may set 'insertmode', and then the opposite problem occurs. But 'insertmode' is
a silly option that shouldn't exist, and any user that uses it probably isn't
fiddling with their cursor shape anyways.)
Also rename the unibilium extensions:
enter_insert_mode => set_cursor_shape_bar
enter_replace_mode => set_cursor_shape_underline
exit_insert_mode => set_cursor_shape_block
to say explicitly what they do in the context of a terminal; it's irrelevant in
this context what purpose they serve in Nvim.
`lib/queue.h` implements a basic queue. `event/queue.c` implements
a specialized data structure on top of lib/queue.h; it is not a "normal"
queue.
Rename the specialized multi-level queue implemented in event/queue.c to
"multiqueue", to avoid confusion when reading the code.
Before this change one can eventually notice that "macros (uppercase
symbols) are for the normal queue, lowercase operations are for the
multi-level queue", but that is unnecessary friction for new developers
(or existing developers just visiting this part of the codebase).
In Vim's main_loop function, the main loop is
while (!cmdwin
#ifdef FEAT_CMDWIN
|| cmdwin_result == 0
#endif
)
{
...
#ifdef FEAT_EVAL
/*
* May perform garbage collection when waiting for a character, but
* only at the very toplevel. Otherwise we may be using a List or
* Dict internally somewhere.
* "may_garbage_collect" is reset in vgetc() which is invoked through
* do_exmode() and normal_cmd().
*/
may_garbage_collect = (!cmdwin && !noexmode);
#endif
/*
* If we're invoked as ex, do a round of ex commands.
* Otherwise, get and execute a normal mode command.
*/
if (exmode_active)
{
if (noexmode) /* End of ":global/path/visual" commands */
return;
do_exmode(exmode_active == EXMODE_VIM);
}
else
normal_cmd(&oa, TRUE);
}
cmdwin_result is set to 0 before calling main_loop to handle the cmdwin
window and gets changed when the user causes a command to execute
(either through pressing <CR> or <C-c>). This means that when the
cmdwin isn't active OR the user is still editing their command,
main_loop runs and main_loop calls normal_cmd with toplevel true as long
as exmode isn't active.
When the normal mode state was extracted in dae006a9, the conditions for
toplevel and may_garbage_collect were combined. Since toplevel was set
to always ignore cmdwin, the v:count(1) variables were no longer being
updated when a command was prefixed with a count in the cmdwin.
Closes#5404
