Problem: The typebuf_was_filled flag is sometimes not reset, which may
cause a hang.
Solution: Make sure typebuf_was_filled is reset when the typeahead buffer is
empty.
e49b4bb895
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: inefficient use of ga_concat()
Solution: Use ga_concat_len() when length is known.
(John Marriott)
closes: vim/vim#1902732b801abc3
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: When waiting for a character is interrupted by receiving channel
data and the first character of a mapping was typed, the mapping
times out. (Ramel Eshed)
Solution: When dealing with channel data don't return from mch_inchar().
cda7764d8e
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Wrong cursor position after formatting with long 'formatprg'.
Solution: Don't show hit-enter prompt when there are stuffed characters.
Previously a stuffed character at the hit-enter prompt will dismiss the
prompt immediately and be put in the typeahead buffer, which leads to
incorrect behavior as the typeahead buffer is processed after the stuff
buffers. Using vungetc() when KeyStuffed is TRUE can fix this problem,
but since the hit-enter prompt isn't visible anyway (and is likely not
desired here), just skip the prompt instead, which also avoids a wait
when using "wait" instead of "hit-enter" in 'messagesopt'.
fixes: vim/vim#18905closes: vim/vim#1890650325c3d59
Technically the current behavior does match documentation. However, the
keys following <Cmd>/K_LUA aren't normally received by vim.on_key()
callbacks either, so it does makes sense to discard them along with the
preceding key.
One may also argue that vim.on_key() callbacks should instead receive
the following keys together with the <Cmd>/K_LUA, but doing that may
cause some performance problems, and even in that case the keys should
still be discarded together.
Problem:
Multigrid UIs have to find out which window to send the input by using
the Nvim focus rules, which are not fully documented.
Furthermore,`getmousepos()` has several problems when multigrid is
enabled, with the main one being that screenrow and screencol are window
relative instead of screen relative, due to the fact that the UI don't
send any absolute coordinates.
Solution:
Allow passing 0 as grid to `nvim_input_mouse`, with absolute
coordinates, which lets nvim determine the actual window to send the
mouse input to. This works as long as nvim is in charge of the window
positioning. If the UI repositions or resizes the windows, it can still
pass the grid it determines like before.
Problem: FEAT_TEXT_PROP is a confusing name.
Solution: Use FEAT_PROP_POPUP. (Naruhiko Nishino, closesvim/vim#5291)
05ad5ff0ab
textprop,popuwin remain N/A features.
getchar.c has the relevant code changes.
Port runtest.vim changes from patch v8.1.1561.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
Problem: Functions used in one file are global.
Solution: Add "static". (Yegappan Lakshmanan, closesvim/vim#4840)
5843f5f37b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Since 48e2a736, prompt messages are handled by an actual
active cmdline, resulting in `State` no longer being equal
to `MODE_CONFIRM` which is used in some places. E.g. to
specify the current `mode()` or to re-emit a confirm message.
Solution: Replace `MODE_CONFIRM` with a new `MODE_CMDLINE` sub-mode when
`ccline.one_key/mouse_used` is set. Use it to avoid clearing
mouse_used prompt messages, and to re-emit one_key messages
(when ext_messages is inactive, for which this is unnecessary).
Problem: Message kind logic for emitting an error message is convoluted
and still results in emitting an unfinished message earlier than
wanted.
Solution: Ensure emsg_multiline() always sets the kind wanted by the caller
and doesn't isn't unset to logic for emitting the source message.
Caller is responsible for making sure multiple message chunks are
not emitted as multiple events by setting `msg_ext_skip_flush`...
Problem: using global variable for get_insert()/get_lambda_name()
(after v9.1.1151)
Solution: let the functions return a string_T object instead
(Yee Cheng Chin)
In vim/vim#16720, `get_insert()` was modified to store a string length in a
global variable to be queried immediately by another `get_insert_len()`
function, which is somewhat fragile. Instead, just have the function
itself return a `string_T` object instead. Also do the same for
`get_lambda_name()` which has similar issues.
closes: vim/vim#167750b5fe42071
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: too many strlen() calls in getchar.c
Solution: store last inserted and recorded lengths,
add functions to retrieve those and use those
functions (John Marriott)
closes: vim/vim#16720d3c4b7e946
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: Cannot control cursor positioning of getchar().
Solution: Add "cursor" flag to {opts}, with possible values "hide",
"keep" and "msg".
related: vim/vim#10603closes: vim/vim#16569edf0f7db28
Problem: getchar() can't distinguish between C-I and Tab.
Solution: Add {opts} to pass extra flags to getchar() and getcharstr(),
with "number" and "simplify" keys.
related: vim/vim#10603closes: vim/vim#16554e0a2ab397f
Cherry-pick tv_dict_has_key() from patch 8.2.4683.
This commit adds basic support for the kitty keyboard protocol to
Neovim's builtin terminal. For now only the first mode ("Disambiguate
escape codes") is supported.
The code represents a useful pattern in normal mode where remapping
`<tab>` will implicitly also remap `<c-i>` unless you remap that
explicitly. This relies on the _unmapped_ behavior being identical which
is not true in terminal mode, as vterm can distinguish these keys.
Vim seems to entangle this with kitty keyboard mode detection which
is irrelevant for us. Conditional fallbacks depending on
keyboard mode could be done completely inside `vterm/` without getchar.c
getting involved, I would think.
Problem: Option metadata like list of valid values for an option and
option flags are not listed in the `options.lua` file and are instead
manually defined in C, which means option metadata is split between
several places.
Solution: Put metadata such as list of valid values for an option and
option flags in `options.lua`, and autogenerate the corresponding C
variables and enums.
Supersedes #28659
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: too many strlen() calls in getchar.c
Solution: refactor code and reduce strlen() calls
(John Marriott)
closes: vim/vim#16017e7a1bbf210
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: When using nvim_paste in a mapping during a macro recording,
both the mapping and the paste are recorded, causing the paste
to be performed twice when replaying the macro.
Solution: Only record a paste when it is from RPC.
Unfortunately this means there is no way for a script to make a recorded
paste. A way to enable that can be discussed later if there is need.
- Fixes 'autoindent' being applied during redo.
- Makes redoing a large paste significantly faster.
- Stores pasted text in the register being recorded.
Fix#28561
Problem:
The name `os_inchar` (from Vim's old `mch_inchar`) is ambiguous:
"inchar" sounds like it could be reading or enqueuing (setting) input.
Its docstring is also ambiguous.
Solution:
- Rename `os_inchar` to `input_get`.
- Write some mf'ing docstrings.
- Add assert() in TRY_READ().
Problem:
Variables are often assigned multiple places in common patterns.
Solution:
Replace these common patterns with different patterns that reduce the
number of assignments.
Use `MAX` and `MIN`:
```c
if (x < y) {
x = y;
}
// -->
x = MAX(x, y);
```
```c
if (x > y) {
x = y;
}
// -->
x = MIN(x, y);
```
Use ternary:
```c
int a;
if (cond) {
a = b;
} els {
a = c;
}
// -->
int a = cond ? b : c;
```
Problem: Check that mapping rhs starts with lhs doesn't work if lhs is
not simplified.
Solution: Keep track of the mapblock containing the alternative lhs and
also compare with it (zeertzjq).
fixes: vim/vim#15376closes: vim/vim#153849d997addc7
Cherry-pick removal of save_m_str from patch 8.2.4059.
Problem: An :lmap mapping for a printable keypad key is not applied
when typing it in Select mode.
Solution: Change keypad key to ASCII after setting vgetc_char.
(zeertzjq)
closes: vim/vim#1524590a800274d
Problem: Crash when typing many keys with D- modifier (after 9.1.0227).
Solution: Don't treat a 0x80 byte inside a special sequence as the start
of a special sequence (zeertzjq).
closes: vim/vim#146136b13e3d4e4
Problem: Using xstrlcpy() when the exact length of the string to be
copied is known is not ideal because it requires adding 1 to
the length and an unnecessary strlen().
Solution: Add xmemcpyz() and use it in place of such xstrlcpy() calls.
Problem: No test that completing a partial mapping clears 'showcmd'.
Solution: Complete partial mappings in Test_showcmd_part_map() instead
of using :echo. Adjust some comments (zeertzjq).
closes: vim/vim#14580094c4390bd
Problem: 'showcmd' is wrong for partial mapping with multibyte char,
and isn't very readable with modifyOtherKeys.
Solution: Decode multibyte char and merge modifiers into the char.
(zeertzjq)
This improves the following situations:
- Multibyte chars whose individual bytes are considered unprintable are
now shown properly in 'showcmd' area.
- Ctrl-W with modifyOtherKeys now shows ^W in 'showcmd' area.
The following situation may still need improvement:
- If the char is a special key or has modifiers that cannot be merged
into it, internal keycodes are shown in 'showcmd' area like before.
This applies to keys typed in Normal mode commands as well, and it's
hard to decide how to make it more readable due to the limited space
taken by 'showcmd', so I'll leave it for later.
closes: vim/vim#14572acdfb8a979
Problem: Recording may still be wrong in Select mode (after 8.2.3993).
Solution: Make sure a character isn't split between two buffer blocks.
(zeertzjq)
closes: vim/vim#14326ea95f1a5ad