aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/options.lua
Commit message (Collapse)AuthorAge
...
* feat(exrc): search in parent directories (#33889)Yochem van Rosmalen2025-05-11
| | | | | | | | | | feat(exrc): search exrc in parent directories Problem: `.nvim.lua` is only loaded from current directory, which is not flexible when working from a subfolder of the project. Solution: Also search parent directories for configuration file.
* vim-patch:0553f2f: runtime(doc): clarify single/multibyte support for ↵zeertzjq2025-05-10
| | | | | | | | | 'fillchars' (#33941) closes: vim/vim#17287 https://github.com/vim/vim/commit/0553f2ff0d170db3f4649a7aaa74b635b1101eed Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
* vim-patch:9.1.1374: completion: 'smartcase' not respected when filtering matcheszeertzjq2025-05-09
| | | | | | | | | | | | | | | | | | | | Problem: Currently, 'smartcase' is respected when completing keywords using <C-N>, <C-P>, <C-X><C-N>, and <C-X><C-P>. However, when a user continues typing and the completion menu is filtered using cached matches, 'smartcase' is not applied. This leads to poor-quality or irrelevant completion suggestions, as shown in the example below. Solution: When filtering cached completion items after typing additional characters, apply case-sensitive comparison if 'smartcase' is enabled and the typed pattern includes uppercase characters. This ensures consistent and expected completion behavior. (Girish Palya) closes: vim/vim#17271 https://github.com/vim/vim/commit/dc314053e121b0a995bdfbcdd2f03ce228e14eb3 Co-authored-by: Girish Palya <girishji@gmail.com>
* vim-patch:fb08192: runtime(doc): clarify the use of 'tagfunc', update a ↵zeertzjq2025-05-01
| | | | | | | | | | comment in tags.c related: vim/vim#17228 https://github.com/vim/vim/commit/fb08192ca75344d6467f9e7f9b9e6d4509df308a Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:partial:fa8b7db: runtime(doc): tweak documentation style in ↵zeertzjq2025-05-01
| | | | | | | | | | options.txt closes: vim/vim#17229 https://github.com/vim/vim/commit/fa8b7db99afad9074e4e1f89b49046836ac61d5b Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
* Merge pull request #33667 from glepnir/vim-9.1.1341zeertzjq2025-04-29
|\ | | | | vim-patch: 9.1.{1341,1344}
| * vim-patch:ffc89e4 runtime(doc): clarify complete_match() and 'isexpand' optionglepnir2025-04-29
| | | | | | | | | | | | | | | | | | | | clarify complete_match() documentation to better explain its backward search behavior, argument handling, and return value format and add an example of isexpand closes: https://github.com/vim/vim/pull/17212 https://github.com/vim/vim/commit/ffc89e47d014178bcd0a681ff2c8e18470cc972b
| * vim-patch:9.1.1341: cannot define completion triggersglepnir2025-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Cannot define completion triggers and act upon it Solution: add the new option 'isexpand' and add the complete_match() function to return the completion matches according to the 'isexpand' setting (glepnir) Currently, completion trigger position is determined solely by the 'iskeyword' pattern (\k\+$), which causes issues when users need different completion behaviors - such as triggering after '/' for comments or '.' for methods. Modifying 'iskeyword' to include these characters has undesirable side effects on other Vim functionality that relies on keyword definitions. Introduce a new buffer-local option 'isexpand' that allows specifying different completion triggers and add the complete_match() function that finds the appropriate start column for completion based on these triggers, scanning backwards from cursor position. This separation of concerns allows customized completion behavior without affecting iskeyword-dependent features. The option's buffer-local nature enables per-filetype completion triggers. closes: vim/vim#16716 https://github.com/vim/vim/commit/bcd5995b40a1c26e735bc326feb2e3ac4b05426b Co-authored-by: glepnir <glephunter@gmail.com>
* | Merge #33542 shada improvementsJustin M. Keyes2025-04-27
|\ \ | | | | | | | | | | | | | | | * feat(shada): don't store jumplist if '0 in 'shada' * fix(shada): don't store search and sub patterns if /0 in 'shada' * fix(shada): don't store empty replacement string * fix(shada): don't add '0' mark if f0 in 'shada'
| * | feat(shada): don't store jumplist if '0 in 'shada'Andre Toerien2025-04-27
| |/
* / docs: lsp, emoji, startup #33446Justin M. Keyes2025-04-27
|/ | | Co-authored-by: Maria José Solano <majosolano99@gmail.com>
* feat(options): default statusline expression #33036Shadman2025-04-21
| | | | | | | | | | Problem: Default 'statusline' is implemented in C and not representable as a statusline expression. This makes it hard for user configs/plugins to extend it. Solution: - Change the default 'statusline' slightly to a statusline expression. - Remove the C implementation.
* vim-patch:2398460: runtime(doc): clarify 'includeexpr' is not used for ↵zeertzjq2025-04-19
| | | | | | | | | <cfile> (#33540) fixes: vim/vim#17139 https://github.com/vim/vim/commit/23984602327600b7ef28dcedc772949d5c66b57f Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:cb3b752: runtime(doc): clarify "nearest" value for 'completeopt' ↵zeertzjq2025-04-19
| | | | | | | | | (#33534) closes: vim/vim#17146 https://github.com/vim/vim/commit/cb3b752f9523060d3feaee33049d2092c288fca2 Co-authored-by: Girish Palya <girishji@gmail.com>
* fix(spell): save spell files to stdpath('data')/site/spell #33528Au.2025-04-18
|
* vim-patch:9.1.1296: completion: incorrect truncation logiczeertzjq2025-04-17
| | | | | | | | | | | | Problem: completion: incorrect truncation logic (after: v9.1.1284) Solution: replace string allocation with direct screen rendering and fixe RTL/LTR truncation calculations (glepnir) closes: vim/vim#17081 https://github.com/vim/vim/commit/d4dbf822dcb9fd95379bebab85def391e1179b21 Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:9.1.1284: not possible to configure pum truncation charzeertzjq2025-04-17
| | | | | | | | | | | | | Problem: not possible to configure the completion menu truncation character Solution: add the "trunc" suboption to the 'fillchars' setting to configure the truncation indicator (glepnir). closes: vim/vim#17006 https://github.com/vim/vim/commit/b87620466c6500fb37fd9be1016a27fa9626749a Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:9.1.1308: completion: cannot order matches by distance to cursor ↵zeertzjq2025-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#33491) Problem: During insert-mode completion, the most relevant match is often the one closest to the cursor—frequently just above the current line. However, both `<C-N>` and `<C-P>` tend to rank candidates from the current buffer that appear above the cursor near the bottom of the completion menu, rather than near the top. This ordering can feel unintuitive, especially when `noselect` is active, as it doesn't prioritize the most contextually relevant suggestions. Solution: This change introduces a new sub-option value "nearest" for the 'completeopt' setting. When enabled, matches from the current buffer are prioritized based on their proximity to the cursor position, improving the relevance of suggestions during completion (Girish Palya). Key Details: - Option: "nearest" added to 'completeopt' - Applies to: Matches from the current buffer only - Effect: Sorts completion candidates by their distance from the cursor - Interaction with other options: - Has no effect if the `fuzzy` option is also present This feature is helpful especially when working within large buffers where multiple similar matches may exist at different locations. You can test this feature with auto-completion using the snippet below. Try it in a large file like `vim/src/insexpand.c`, where you'll encounter many potential matches. You'll notice that the popup menu now typically surfaces the most relevant matches—those closest to the cursor—at the top. Sorting by spatial proximity (i.e., contextual relevance) often produces more useful matches than sorting purely by lexical distance ("fuzzy"). Another way to sort matches is by recency, using an LRU (Least Recently Used) cache—essentially ranking candidates based on how recently they were used. However, this is often overkill in practice, as spatial proximity (as provided by the "nearest" option) is usually sufficient to surface the most relevant matches. ```vim set cot=menuone,popup,noselect,nearest inf def SkipTextChangedIEvent(): string # Suppress next event caused by <c-e> (or <c-n> when no matches found) set eventignore+=TextChangedI timer_start(1, (_) => { set eventignore-=TextChangedI }) return '' enddef autocmd TextChangedI * InsComplete() def InsComplete() if getcharstr(1) == '' && getline('.')->strpart(0, col('.') - 1) =~ '\k$' SkipTextChangedIEvent() feedkeys("\<c-n>", "n") endif enddef inoremap <silent> <c-e> <c-r>=<SID>SkipTextChangedIEvent()<cr><c-e> inoremap <silent><expr> <tab> pumvisible() ? "\<c-n>" : "\<tab>" inoremap <silent><expr> <s-tab> pumvisible() ? "\<c-p>" : "\<s-tab>" ``` closes: vim/vim#17076 https://github.com/vim/vim/commit/b156588eb707a084bbff8685953a8892e1e45bca Co-authored-by: Girish Palya <girishji@gmail.com>
* vim-patch:f4b1a60: runtime(doc): update options.txt and clarify 'wildmode' ↵zeertzjq2025-04-14
| | | | | | | | | | | further related: vim/vim#17100 https://github.com/vim/vim/commit/f4b1a60dd145c8dddd2b6a37699e96772cd69402 Co-authored-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Girish Palya <girishji@gmail.com>
* vim-patch:eded336: runtime(doc): Improve 'wildmode' setting desciptionzeertzjq2025-04-14
| | | | | | | | closes: vim/vim#17100 https://github.com/vim/vim/commit/eded33621be29b9fdc51466efdc946fa8d3e756f Co-authored-by: Girish Palya <girishji@gmail.com>
* feat(defaults): shelltemp=false #33012Alexej Kowalew2025-04-12
| | | | Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* vim-patch:9.1.1288: Using wrong window in ll_resize_stack() (#33397)zeertzjq2025-04-09
| | | | | | | | | | Problem: Using wrong window in ll_resize_stack() (after v9.1.1287) Solution: Use "wp" instead of "curwin", even though they are always the same value. Fix typos in documentation (zeertzjq). closes: vim/vim#17080 https://github.com/vim/vim/commit/b71f1309a210bf8f61a24f4eda336de64c6f0a07
* vim-patch:9.1.1283: quickfix stack is limited to 10 itemszeertzjq2025-04-08
| | | | | | | | | | | | | | Problem: quickfix and location-list stack is limited to 10 items Solution: add the 'chistory' and 'lhistory' options to configure a larger quickfix/location list stack (64-bitman) closes: vim/vim#16920 https://github.com/vim/vim/commit/88d41ab270a8390a43da97a903b1a4d76b89d330 Co-authored-by: 64-bitman <60551350+64-bitman@users.noreply.github.com> Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
* fix(defaults): keywordprg=:help on Windows #33336Emanuel Krollmann2025-04-07
| | | | | | | | | | Problem: As `:h kp` says, the default value for keywordprg should be ':help' on Windows. It is currently always ':Man'. Solution: Add condition to options.lua which sets keywordprg to ':help' if running on windows.
* docs: clipboard, eval #33223Justin M. Keyes2025-04-05
|
* vim-patch:9.1.1276: inline word diff treats multibyte chars as word char ↵zeertzjq2025-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#33323) Problem: inline word diff treats multibyte chars as word char (after 9.1.1243) Solution: treat all non-alphanumeric characters as non-word characters (Yee Cheng Chin) Previously inline word diff simply used Vim's definition of keyword to determine what is a word, which leads to multi-byte character classes such as emojis and CJK (Chinese/Japanese/Korean) characters all classifying as word characters, leading to entire sentences being grouped as a single word which does not provide meaningful information in a diff highlight. Fix this by treating all non-alphanumeric characters (with class number above 2) as non-word characters, as there is usually no benefit in using word diff on them. These include CJK characters, emojis, and also subscript/superscript numbers. Meanwhile, multi-byte characters like Cyrillic and Greek letters will still continue to considered as words. Note that this is slightly inconsistent with how words are defined elsewhere, as Vim usually considers any character with class >=2 to be a "word". related: vim/vim#16881 (diff inline highlight) closes: vim/vim#17050 https://github.com/vim/vim/commit/9aa120f7ada592ed03b37f4de8ee413c5385f123 Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
* feat(defaults): store spellfile in stdpath('data') #33048Yochem van Rosmalen2025-04-04
| | | | | | | | | | | Problem: First rtp directory is unpredictable and not in line with XDG base spec. Solution: Use stdpath('data')/spell as directory if 'spellfile' is not set. Co-authored-by: zeertzjq <zeertzjq@outlook.com> Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* feat(float): 'winborder' "bold" style #33189glepnir2025-03-31
|
* vim-patch:9.1.1250: cannot set the maximum popup menu widthzeertzjq2025-03-29
| | | | | | | | | | | | | | Problem: cannot set the maximum popup menu width (Lucas Mior) Solution: add the new global option value 'pummaxwidth' (glepnir) fixes: vim/vim#10901 closes: vim/vim#16943 https://github.com/vim/vim/commit/88d75934c3d5bc4c406343f106e1a61638abd3a7 Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:9.1.1252: typos in code and docs related to 'diffopt' "inline:" ↵zeertzjq2025-03-29
| | | | | | | | | | | | (#33143) Problem: Typos in code and docs related to 'diffopt' "inline:". (after v9.1.1243) Solution: Fix typos and slightly improve the docs. (zeertzjq) closes: vim/vim#16997 https://github.com/vim/vim/commit/5a307c361cbe9f7ac438a917b905378d87f8f2de
* vim-patch:9.1.1243: diff mode is lacking for changes within lineszeertzjq2025-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Diff mode's inline highlighting is lackluster. It only performs a line-by-line comparison, and calculates a single shortest range within a line that could encompass all the changes. In lines with multiple changes, or those that span multiple lines, this approach tends to end up highlighting much more than necessary. Solution: Implement new inline highlighting modes by doing per-character or per-word diff within the diff block, and highlight only the relevant parts, add "inline:simple" to the defaults (which is the old behaviour) This change introduces a new diffopt option "inline:<type>". Setting to "none" will disable all inline highlighting, "simple" (the default) will use the old behavior, "char" / "word" will perform a character/word-wise diff of the texts within each diff block and only highlight the differences. The new char/word inline diff only use the internal xdiff, and will respect diff options such as algorithm choice, icase, and misc iwhite options. indent-heuristics is always on to perform better sliding. For character highlight, a post-process of the diff results is first applied before we show the highlight. This is because a naive diff will create a result with a lot of small diff chunks and gaps, due to the repetitive nature of individual characters. The post-process is a heuristic-based refinement that attempts to merge adjacent diff blocks if they are separated by a short gap (1-3 characters), and can be further tuned in the future for better results. This process results in more characters than necessary being highlighted but overall less visual noise. For word highlight, always use first buffer's iskeyword definition. Otherwise if each buffer has different iskeyword settings we would not be able to group words properly. The char/word diffing is always per-diff block, not per line, meaning that changes that span multiple lines will show up correctly. Added/removed newlines are not shown by default, but if the user has 'list' set (with "eol" listchar defined), the eol character will be be highlighted correctly for the specific newline characters. Also, add a new "DiffTextAdd" highlight group linked to "DiffText" by default. It allows color schemes to use different colors for texts that have been added within a line versus modified. This doesn't interact with linematch perfectly currently. The linematch feature splits up diff blocks into multiple smaller blocks for better visual matching, which makes inline highlight less useful especially for multi-line change (e.g. a line is broken into two lines). This could be addressed in the future. As a side change, this also removes the bounds checking introduced to diff_read() as they were added to mask existing logic bugs that were properly fixed in vim/vim#16768. closes: vim/vim#16881 https://github.com/vim/vim/commit/9943d4790e42721a6777da9e12637aa595ba4965 Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
* vim-patch:9.1.1201: 'completefuzzycollect' does not handle dictionary correctlyzeertzjq2025-03-27
| | | | | | | | | | | | | Problem: 'completefuzzycollect' does not handle dictionary correctly Solution: check for ctrl_x_mode_dictionary (glepnir) closes: vim/vim#16867 https://github.com/vim/vim/commit/587601671cd06ddc4d78f907d98578cdab96003f Cherry-pick a documentation fix from later. Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:1dc731a: runtime(doc): make :h 'completefuzzycollect' a bit clearerzeertzjq2025-03-27
| | | | | | | | | | | - Fix grammar - Use "matches" instead of "items" ("completion candidates" is used in some other places, but it's a bit verbose) - "When set" is a bit vague, instead use "For specified modes" closes: vim/vim#16871 https://github.com/vim/vim/commit/1dc731a49ff5d06ead4b506afa04288a5baafc1a
* vim-patch:9.1.1197: process_next_cpt_value() uses wrong conditionzeertzjq2025-03-27
| | | | | | | | | | | | Problem: process_next_cpt_value() uses wrong condition Solution: use cfc_has_mode() instead and remove redundant else if branch (glepnir) closes: vim/vim#16833 https://github.com/vim/vim/commit/53b14578e03f93a53fd6eb21c00caf96484742ed Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:9.1.1182: No cmdline completion for 'completefuzzycollect'zeertzjq2025-03-27
| | | | | | | | | | | | | | Problem: No cmdline completion for the 'completefuzzycollect' option (after v9.1.1178) Solution: Add cmdline completion for the 'completefuzzycollect' option, improve its description in optwin.vim (zeertzjq). closes: vim/vim#16813 https://github.com/vim/vim/commit/53d59ecc1d93ce3a3f6d0182479d825852018ceb No code change is needed in Nvim as Nvim uses expand_set_str_generic() by default.
* vim-patch:9.1.1178: not possible to generate completion candidates using ↵zeertzjq2025-03-27
| | | | | | | | | | | | | | | | | | fuzzy matching Problem: not possible to generate completion candidates using fuzzy matching Solution: add the 'completefuzzycollect' option for (some) ins-completion modes (glepnir) fixes vim/vim#15296 fixes vim/vim#15295 fixes vim/vim#15294 closes: vim/vim#16032 https://github.com/vim/vim/commit/f31cfa29bf72b0cdf6fa1b60346ea4e187bcafd1 Co-authored-by: glepnir <glephunter@gmail.com>
* vim-patch:26e4b00: runtime(doc): Revert outdated comment in completeopt's ↵zeertzjq2025-03-27
| | | | | | | | | | | | | | | | fuzzy documentation Originally, `:set completeopt+=fuzzy` did not affect how the candidate list is collected in default keyword completion. A comment was added to documentation as part of vim/vim#14912 to clarify it. vim/vim#15193 later changed the fuzzy behavior to now change the candidate collection behavior as well so the clarification in docs is now wrong. Remove them here. closes: vim/vim#15656 https://github.com/vim/vim/commit/26e4b000025ea0e25ea7877314d9095737431bae Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
* fix(api): fix 'winborder' preventing splits with nvim_open_win (#32981)zeertzjq2025-03-19
| | | | | | While at it, rename the p_winbd variable to p_winborder, as 'winbd' is not the option's short name. Co-authored-by: glepnir <glephunter@gmail.com>
* fix(options): fix 'winborder' accepting multiple string values (#32978)zeertzjq2025-03-19
| | | | | | Problem: 'winborder' accepting multiple string values. Solution: Use the fallback did_set_str_generic() callback instead of did_set_winborder() which calls opt_strings_flags() with incorrect last argument.
* feat(float): add winborder option (#31074)glepnir2025-03-18
| | | | | | | | | Problem: There is currently no global option to define the default border style for floating windows. This leads to repetitive code when developers need consistent styling across multiple floating windows. Solution: Introduce a global option winborder to specify the default border style for floating windows. When a floating window is created without explicitly specifying a border style, the value of the winborder option will be used. This simplifies configuration and ensures consistency in floating window appearance. Co-authored-by: Gregory Anders <greg@gpanders.com>
* docs: miscJustin M. Keyes2025-03-17
|
* feat(defaults): completeopt=popup #32909Justin M. Keyes2025-03-15
| | | | Assuming that completeopt=popup does what its documentation claims, it is more appropriate that completeopt=preview as a default.
* fix(build): vimdoc tags are not validated #32801Justin M. Keyes2025-03-09
| | | | | | | | | Problem: "make lintdoc" is not validating vimdoc (:help) tags. Solution: - Call `lang_tree:parse()` to init the parser. - Load netrw 🤢 explicitly, since it was moved to `pack/dist/opt/`. - Fix invalid help tags.
* vim-patch:659cb28: runtime(doc): fix typo "bet" in :h 'completeopt' (#32711)zeertzjq2025-03-04
| | | | | closes: vim/vim#16773 https://github.com/vim/vim/commit/659cb28c25b756e59c712c337f8b4650e85f8bcd
* vim-patch:9.1.1166: command-line auto-completion hard with wildmenuTomas Slusny2025-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: command-line auto-completion hard with wildmenu Solution: implement "noselect" wildoption value (Girish Palya) When `noselect` is present in `wildmode` and 'wildmenu' is enabled, the completion menu appears without pre-selecting the first item. This change makes it easier to implement command-line auto-completion, where the menu dynamically appears as characters are typed, and `<Tab>` can be used to manually select an item. This can be achieved by leveraging the `CmdlineChanged` event to insert `wildchar(m)`, triggering completion menu. Without this change, auto-completion using the 'wildmenu' mechanism is not feasible, as it automatically inserts the first match, preventing dynamic selection. The following Vimscript snippet demonstrates how to configure auto-completion using `noselect`: ```vim vim9script set wim=noselect:lastused,full wop=pum wcm=<C-@> wmnu autocmd CmdlineChanged : timer_start(0, function(CmdComplete, [getcmdline()])) def CmdComplete(cur_cmdline: string, timer: number) var [cmdline, curpos] = [getcmdline(), getcmdpos()] if cur_cmdline ==# cmdline # Avoid completing each character in keymaps and pasted text && !pumvisible() && curpos == cmdline->len() + 1 if cmdline[curpos - 2] =~ '[\w*/:]' # Reduce noise by completing only selected characters feedkeys("\<C-@>", "ti") set eventignore+=CmdlineChanged # Suppress redundant completion attempts timer_start(0, (_) => { getcmdline()->substitute('\%x00$', '', '')->setcmdline() # Remove <C-@> if no completion items exist set eventignore-=CmdlineChanged }) endif endif enddef ``` fixes: vim/vim#16551 closes: vim/vim#16759 https://github.com/vim/vim/com