aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/keycodes.h
Commit message (Collapse)AuthorAge
* fix(lua): vim.keycode cleanup #40817Justin M. Keyes2026-07-18
|
* feat(lua): vim.keycode() gets structured parse result #38636altermo2026-07-18
| | | | | | | | | | | | | | | | | Problems: 1. Can't get individual parts of a key-chord separately: modifiers, key. 2. Can't separate a key-combo into individual key-chords. Solution: Enhance `vim.keycode()` to optionally return a structured parse result as a list of key-chords: - `key_raw` the key-chord (problem 2) - `mod` the modifiers of `key_raw` (problem 1) - `key_orig` the key part of the key-chord, only here if differing from `key` (this doesn't solve any of the above mentioned problems, but it may provide useful and it's (in terms of code) free) - `key` a normalized version of `key_orig` (solving problem 1), example(the first is `key_orig` and second is `key`): `lt` and `<`, `Bar` and `|` (in `<C-Bar>`)
* vim-patch:9.2.0739: completion: 'autocompletedelay' blocks the main loop and ↵zeertzjq2026-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drops autocommands Problem: With a non-zero 'autocompletedelay', Insert-mode autocommands (TextChangedI, TextChangedP, CursorMovedI) are delayed, and while typing faster than the delay they are dropped entirely, because the delay blocks the main loop. Solution: Make 'autocompletedelay' non-blocking: instead of busy-waiting before showing the popup menu, defer it with an input-wait timeout (K_COMPLETE_DELAY) modeled on CursorHoldI, so typing stays responsive and the Insert-mode autocommands fire normally. The delay timer coexists with 'updatetime': the main loop waits for the sooner of the two and triggers the event whose deadline was reached, so 'autocompletedelay' no longer shadows CursorHold timing. Changing the completion leader, for example with Backspace, updates the visible popup immediately like a zero delay; only the first popup is deferred. Update the 'autocompletedelay' screendumps for the non-blocking display. One test opened the menu with CTRL-N right after the delay expired and could race with the deferred popup, so it now waits a little longer than the delay before sending the key. fixes: vim/vim#20591 closes: vim/vim#20598 https://github.com/vim/vim/commit/8ce43ea4e3cb315f566bcd9048c254ba58042964 Also include some insexpand.c and ui.c changes from patch 9.2.0750. Co-authored-by: Hirohito Higashi <h.east.727@gmail.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(cmdwin): implement cmdwin as a normal buf+winJustin M. Keyes2026-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: cmdwin (the `:q` cmdline buffer) has various limitations which require special-casing all over the codebase. Besides complicating the code, it also breaks async plugins if they try to create buffers/windows after some work is done, if the user happens to open cmdwin at the wrong the moment: Lua callback: …/guh.nvim/lua/guh/util.lua:531: E11: Invalid in command-line window; <CR> executes, CTRL-C quits stack traceback: [C]: in function 'nvim_buf_delete' …/guh.nvim/lua/guh/util.lua:531: in function <…/guh.nvim/lua/guh/util.lua:526> Solution: Just say no to "inception". Reimplement cmdwin as a normal buffer+window. All of the cmdwin contortions (in both core, and innocent plugins) exist literally only to support "inception": recursive cmdwin-in-cmdline-things, like `<c-r>=`, `/`, search-during-substitute, `:input()`, etc. So we just won't support that (though I have a potential plan for that later, which I call "modal parking lot"). The benefit is that plugins, and core, no longer have to care about cmdwin. BONUS: - mouse-drag on vertical separators works (it only worked for horizontal/statusline before) - inccommand-in-cmdwin now works correctly, for free (thus don't need #40077). POTENTIAL FOLLOWUPS - Drop `CHECK_CMDWIN` ("E11: Invalid in command-line window"), allow chaos. - Unify `BUFLOCK_OK` / `LOCK_OK` ? DESIGN: - Eliminate lots of C globals, `EX_CMDWIN`, etc. - `text_locked()` no longer reports true for cmdwin. - cmdwin = a normal window with 'winfixbuf', 'bufhidden=wipe', 'buftype=nofile'. Invariants come from those options rather than special cases throughout the codebase. - `nv_record` for q:/q//q? calls Lua `nlua_call_vimfn("vim._core.cmdwin", …)`. No `K_CMDWIN` / cmdline-reader detour. - `cedit_key` (`c_CTRL-F`) schedules a deferred event that calls `vim._core.cmdwin.open(type, content, pos)` and returns `Ctrl_C` so the in-flight cmdline cancels. Reader state is not serialized; instead the captured `(type, line, col)` is replayed via `nvim_feedkeys(type..line.."<CR>", "nt", …)` after user confirms. - On confirm/cancel: `<CR>` / `<C-C>` calls into Lua which closes the window and re-feeds the cmdline. BREAKING CHANGES: - Expression-register cmdline (`<C-R>=` from insert-mode) no longer supports cmdwin. Same applies to `input()` / `inputlist()` (already covered by `text_locked`). - Usage of cmdwin in macros/mappings will probably break (assuming they ever worked).
* refactor(build): remove INCLUDE_GENERATED_DECLARATIONS guardsbfredl2025-08-14
| | | | | | | | | 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.
* vim-patch:9.1.1576: cannot easily trigger wildcard expansion (#35022)zeertzjq2025-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: cannot easily trigger wildcard expansion Solution: Introduce wildtrigger() function (Girish Palya) This PR introduces a new `wildtrigger()` function. See `:h wildtrigger()` `wildtrigger()` behaves like pressing the `wildchar,` but provides a more refined and controlled completion experience: - Suppresses beeps when no matches are found. - Avoids displaying irrelevant completions (like full command lists) when the prefix is insufficient or doesn't match. - Skips completion if the typeahead buffer has pending input or if a wildmenu is already active. - Does not print "..." before completion. This is an improvement on the `feedkeys()` based autocompletion script given in vim/vim#16759. closes: vim/vim#17806 https://github.com/vim/vim/commit/b486ed8266d3b8cd1ffab7d7f302fbd6d5a55c70 While at it, also make Ctrl-Z trigger search completion. Co-authored-by: Girish Palya <girishji@gmail.com>
* fix(keycodes): recognize <Find>, <Select> #28431Mantas Mikulėnas2025-02-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PuTTY sets TERM=xterm, but sends ESC[1~ and ESC[4~ for Home/End keys, which does not match what the 'xterm' terminfo has for khome/kend, so libtermkeys instead reports them as the original DEC VT220 names. The VT220 came with a DEC LK201 keyboard which had the following keys in the area above arrow keys (where PCs now have Ins/Del/Home/End/etc): ┌────────┬────────┬────────┐ │ Find │ Insert │ Re- │ │ │ Here │ move │ ├────────┼────────┼────────┤ │ Select │ Prev │ Next │ │ │ Screen │ Screen │ └────────┴────────┴────────┘ These would send ESC[x~ sequences in the expected order: ┌────────┬────────┬────────┐ │ ESC[1~ │ ESC[2~ │ ESC[3~ │ ├────────┼────────┼────────┤ │ ESC[4~ │ ESC[5~ │ ESC[6~ │ └────────┴────────┴────────┘ Modern terminals continue to use the same sequences for Ins/Del as well as PageUp/PageDn. But the VT220 keyboard apparently had no Home/End, and PuTTY apparently chose to re-purpose the Find/Select key sequences for Home/End (even though it claims to emulate Xterm and this doesn't match what actual Xterm does). So when Home/End are used in Neovim through PuTTY with TERM=xterm (the default setting), libtermkey finds no match for the received sequences in the terminfo database and defaults to reporting them as <Find> and <Select> respectively. PuTTY is not unique here -- tmux *also* sends ESC[1~ and ESC[4~ after its internal translation -- but the difference is that 'tmux' terminfo correctly maps them to Home/End so Neovim recognizes them as such, while PuTTY defaults to using 'xterm' which uses a different mapping. This initial patch only allows Neovim to recognize <Find> and <Select> key codes as themselves, so that the user could manually map them e.g. using ":imap <Find> <Home>". Alternatives: - Using TERM=putty(-256color) would of course be the most correct solution, but in practice it leads to other minor issues, e.g. the need to have different PuTTY config profiles for older or non-Linux systems that lack that terminfo, or tmux's insistence on rendering italics as reverse. - Using Neovim through tmux avoids the problem (as tmux recognizes ESC[1~ on input), but is something that needs to be manually run every time. The keycodes.h constants are slightly misnamed because K_SELECT was already taken for a different purpose.
* fix(paste): improve repeating of pasted text (#30438)zeertzjq2024-09-22
| | | | | | | - Fixes 'autoindent' being applied during redo. - Makes redoing a large paste significantly faster. - Stores pasted text in the register being recorded. Fix #28561
* refactor(IWYU): fix headersdundargoc2024-01-11
| | | | | | Remove `export` pramgas from defs headers as it causes IWYU to believe that the definitions from the defs headers comes from main header, which is not what we really want.
* refactor: remove CPO_TO_CPO_FLAGS() (#26718)zeertzjq2023-12-23
| | | | | Just pass p_cpo to replace_termcodes() directly. This allows removing option_vars.h from keycodes.h, and also avoids the mistake of passing 0 as cpo_flags.
* refactor: run IWYU on entire repodundargoc2023-12-21
| | | | Reference: https://github.com/neovim/neovim/issues/6371.
* refactor: fix headers with IWYUdundargoc2023-11-28
|
* refactor: replace manual header guards with #pragma oncedundargoc2023-11-12
| | | | | It is less error-prone than manually defining header guards. Pretty much all compilers support it even if it's not part of the C standard.
* refactor: reorganize option header files (#25437)zeertzjq2023-09-30
| | | | | | - Move vimoption_T to option.h - option_defs.h is for option-related types - option_vars.h corresponds to Vim's option.h - option_defs.h and option_vars.h don't include each other
* refactor: replace char_u with char (#21901)dundargoc2023-02-11
| | | | | refactor: replace char_u with char Work on https://github.com/neovim/neovim/issues/459
* build: allow IWYU to fix includes for all .c filesdundargoc2022-11-15
| | | | | | | | | | Allow Include What You Use to remove unnecessary includes and only include what is necessary. This helps with reducing compilation times and makes it easier to visualise which dependencies are actually required. Work on https://github.com/neovim/neovim/issues/549, but doesn't close it since this only works fully for .c files and not headers.
* docs: fix typos (#19588)dundargoc2022-08-03
| | | | Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: notomo <notomo.motono@gmail.com>
* refactor: replace char_u variables and functions with charDundar Goc2022-05-16
| | | | Work on https://github.com/neovim/neovim/issues/459
* refactor: rename keymap.{c,h} to keycodes.{c,h} (#18535)zeertzjq2022-05-12
Most code in keymap.h is for keycode definitions, while most code in keymap.c is for the parsing and conversion of keycodes. The name "keymap" may also make people think these two files are for mappings, while in fact keycodes are used even when no mappings are involved, so "keycodes" should be a better file name than "keymap".
generated by cgit (git 2.34.1) at 2026-10-20 12:39:22 +0000