this is consistent with vim, and is necessary for plugins that implement
their own input modes using "getchar()" and still want to do async
event processing.
Problem:
When '--embed' passed to command line arguments, stdin and stdout
are used for IPC. But when multiple files are passed as
arguments, nvim wrongly sends 'N files to edit' message to its
stdout. As the result, attaching to process from frontend failed.
Solution:
Remove the message because it doesn't fill any purpose.
Problem: Command line completion on "find **/filename" drops sub-directory.
Solution: Handle this case separately. (Harm te Hennepe, closesvim/vim#932, closes
vim/vim#939)
73d4e4c892
Check `exists('b:term_title')` to avoid the BufReadCmd for already-initialized
:terminal buffers.
Move the test for `:argadd`.
Add a test for `:edit<CR>`.
Tweak comments and code style.
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`.
../src/nvim/if_cscope.c: In function 'cs_read_prompt':
../src/nvim/if_cscope.c:1771:47: warning: comparison is always true due to limited range of data type [-Wtype-limits]
while ((ch = (char)getc(csinfo[i].fr_fp)) != EOF && ch != CSCOPE_PROMPT[0])
^~
../src/nvim/if_cscope.c:1804:14: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (ch == EOF) {
^~
../src/nvim/if_cscope.c:1816:14: warning: negative integer implicitly converted to unsigned type [-Wsign-conversion]
ch = EOF;
^~~
../src/nvim/if_cscope.c:1821:12: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (ch == EOF)
^~
Since EOF is -1, it will be converted to a large unsigned value to
compare with unsigned char and never match. Use an int to store the
return from getc so we can safely compare it and, once known to be
valid, cast it to char when storing it into buf.
Signed-off-by: James McCoy <jamessan@jamessan.com>
This fixes the -Wconversion warning when char's type is unsigned.
../src/nvim/ex_eval.c: In function 'ex_while':
../src/nvim/ex_eval.c:1000:28: warning: conversion to 'char' from 'int' may alter its value [-Wconversion]
cstack->cs_lflags &= ~CSL_HAD_LOOP;
^
Signed-off-by: James McCoy <jamessan@jamessan.com>
Problem: Cannot use a window ID where a window number is expected.
Solution: Add LOWEST_WIN_ID, so that the window ID can be used where a
number is expected.
888ccac890
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().
In order to provide better compatibility with the classic bindings, the
API needs to provide the ability to query the number (really index) of
the window/tabpage.
This is needed for neovim/python-client#87, as discussed in
neovim/neovim#1898.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Problem: Non-GUI specific settings in the gvimrc_example file.
Solution: Move some settings to the vimrc_example file. Remove setting
'hlsearch' again. (suggested by Hirohito Higashi)
54f1b7abf8
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).
Problem: Result of getcompletion('', 'cscope') depends on previous
completion. (Christian Brabandt)
Solution: Call set_context_in_cscope_cmd().
b650b9878e
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
