summaryrefslogtreecommitdiffstatshomepage
path: root/src/nvim/keycodes.h
AgeCommit message (Collapse)AuthorFiles
2025-08-14refactor(build): remove INCLUDE_GENERATED_DECLARATIONS guardsbfredl1
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.
2025-07-23vim-patch:9.1.1576: cannot easily trigger wildcard expansion (#35022)zeertzjq1
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>
2025-02-20fix(keycodes): recognize <Find>, <Select> #28431Mantas Mikulėnas1
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.
2024-09-22fix(paste): improve repeating of pasted text (#30438)zeertzjq1
- Fixes 'autoindent' being applied during redo. - Makes redoing a large paste significantly faster. - Stores pasted text in the register being recorded. Fix #28561
2024-01-11refactor(IWYU): fix headersdundargoc1
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.
2023-12-23refactor: remove CPO_TO_CPO_FLAGS() (#26718)zeertzjq1
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.
2023-12-21refactor: run IWYU on entire repodundargoc1
Reference: https://github.com/neovim/neovim/issues/6371.
2023-11-28refactor: fix headers with IWYUdundargoc1
2023-11-12refactor: replace manual header guards with #pragma oncedundargoc1
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.
2023-09-30refactor: reorganize option header files (#25437)zeertzjq1
- 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
2023-02-11refactor: replace char_u with char (#21901)dundargoc1
refactor: replace char_u with char Work on https://github.com/neovim/neovim/issues/459
2022-11-15build: allow IWYU to fix includes for all .c filesdundargoc1
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.
2022-08-03docs: fix typos (#19588)dundargoc1
Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: notomo <notomo.motono@gmail.com>
2022-05-16refactor: replace char_u variables and functions with charDundar Goc1
Work on https://github.com/neovim/neovim/issues/459
2022-05-12refactor: rename keymap.{c,h} to keycodes.{c,h} (#18535)zeertzjq1
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".