aboutsummaryrefslogtreecommitdiff
path: root/runtime/doc/options.txt
Commit message (Collapse)AuthorAge
...
| * feat(tui): add 'termsync' option (#25871)Gregory Anders2023-11-14
| | | | | | | | | | | | | | The 'termsync' option enables a mode (provided the underlying terminal supports it) where all screen updates during a redraw cycle are buffered and drawn together when the redraw is complete. This eliminates tearing or flickering in cases where Nvim redraws slower than the terminal redraws the screen.
| * fix(defaults): set 'fsync' #26034Ploum2023-11-14
| | | | | | | | | | | | | | | | Problem: 'nofsync' may lose data if the system has a hard shutdown. #9888 Solution: Change default to 'fsync'. This may be revisited in the future when 'nofsync' can be made safer.
| * vim-patch:9.0.2103: recursive callback may cause issues on some archs (#26013)zeertzjq2023-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: recursive callback may cause issues on some archs Solution: Decrease the limit drastically to 20 Recursive callback limit causes problems on some architectures Since commit 47510f3d6598a1218958c03ed11337a43b73f48d we have a test that causes a recursive popup callback function to be executed. However it seems the current limit of 'maxfuncdepth' option value is still too recursive for some 32bit architectures (e.g. 32bit ARM). So instead of allowing a default limit of 100 (default value for 'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a use case where one would need such a high recursive callback limit and a limit of 20 seems reasonable (although it is currently hard-coded). closes: vim/vim#13495 closes: vim/vim#13502 https://github.com/vim/vim/commit/2076463e383901cef44685aaf4b63e4306444f9e Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:1b08d2cd0789 (#25993)zeertzjq2023-11-12
| | | | | | | | | | | | | | | | | | runtime(doc): clarify when formatoptions applies closes: vim/vim#13503 https://github.com/vim/vim/commit/1b08d2cd0789fd9aaae148a64ff46342730022d7 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.0.2095: statusline may look different than expected (#25941)zeertzjq2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: statusline may look different than expected Solution: do not check for highlighting of stl and stlnc characters statusline fillchar may be different than expected If the highlighting group for the statusline for the current window |hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared (or do not differ from each other), than Vim will use the hard-coded fallback values '^' (for the non-current windows) or '=' (for the current window). I believe this was done, to make sure the statusline will always be visible and be distinguishable from the rest of the window. However, this may be unexpected, if a user explicitly defined those fillchar characters just to notice that those values are then not used by Vim. So, let's assume users know what they are doing and just always return the configured stl and stlnc values. And if they want the statusline to be non-distinguishable from the rest of the window space, so be it. It is their responsibility and Vim shall not know better what to use. fixes: vim/vim#13366 closes: vim/vim#13488 https://github.com/vim/vim/commit/6a650bf696f1df3214b3d788947447c5bbf1a77d Co-authored-by: Christian Brabandt <cb@256bit.org>
| * docs: small fixes (#25585)dundargoc2023-10-29
| | | | | | | | Co-authored-by: tmummert <doczook@gmx.de> Co-authored-by: parikshit adhikari <parikshitadhikari@gmail.com>
| * vim-patch:8ebdbc9e6d80 (#25816)zeertzjq2023-10-29
| | | | | | | | | | | | | | | | | | | | runtime(doc): all secure options should note this restriction in the documentation (vim/vim#13448) Problem: Not all secure options document their status Solution: Describe secure context :set restrictions in each help entry https://github.com/vim/vim/commit/8ebdbc9e6d80b707c2b2d923e702dc86bf902923 Co-authored-by: dkearns <dougkearns@gmail.com>
| * vim-patch:partial:5985879e3c36 (#25780)zeertzjq2023-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | runtime(doc): Fix typos in several documents (vim/vim#13420) * Fix typos in several documents * Update runtime/doc/terminal.txt https://github.com/vim/vim/commit/5985879e3c36383155f84649fa42d06813a1893e Skip runtime/doc/indent.txt: not ported yet Co-authored-by: h_east <h.east.727@gmail.com> Co-authored-by: K.Takata <kentkt@csc.jp>
| * feat(complete): support f flag for complete buffer partglepnir2023-10-21
| |
| * vim-patch:9.0.2035: [security] use-after-free with wildmenu (#25687)zeertzjq2023-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: [security] use-after-free with wildmenu Solution: properly clean up the wildmenu when exiting Fix wildchar/wildmenu/pum memory corruption with special wildchar's Currently, using `wildchar=<Esc>` or `wildchar=<C-\>` can lead to a memory corruption if using wildmenu+pum, or wrong states if only using wildmenu. This is due to the code only using one single place inside the cmdline process loop to perform wild menu clean up (by checking `end_wildmenu`) but there are other odd situations where the loop could have exited and we need a post-loop clean up just to be sure. If the clean up was not done you would have a stale popup menu referring to invalid memory, or if not using popup menu, incorrect status line (if `laststatus=0`). For example, if you hit `<Esc>` two times when it's wildchar, there's a hard-coded behavior to exit command-line as a failsafe for user, and if you hit `<C-\><C-\><C-N>` it will also exit command-line, but the clean up code would not have hit because of specialized `<C-\>` handling. Fix Ctrl-E / Ctrl-Y to not cancel/accept wildmenu if they are also used for 'wildchar'/'wildcharm'. Currently they don't behave properly, and also have potentially memory unsafe behavior as the logic is currently not accounting for this situation and try to do both. (Previous patch that addressed this: vim/vim#11677) Also, correctly document Escape key behavior (double-hit it to escape) in wildchar docs as it's previously undocumented. In addition, block known invalid chars to be set in `wildchar` option, such as Ctrl-C and `<CR>`. This is just to make it clear to the user they shouldn't be set, and is not required for this bug fix. closes: vim/vim#13361 https://github.com/vim/vim/commit/8f4fb007e4d472b09ff6bed9ffa485e0c3093699 Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
| * vim-patch:9.0.2030: no max callback recursion limit (#25655)zeertzjq2023-10-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: no max callback recursion limit Solution: bail out, if max call recursion for callback functions has been reached. This checks the 'maxfuncdepth' setting and throws E169 when a callback function recursively calls itself. closes: vim/vim#13337 closes: vim/vim#13339 https://github.com/vim/vim/commit/47510f3d6598a1218958c03ed11337a43b73f48d Co-authored-by: Christian Brabandt <cb@256bit.org>
| * docs: restore accidentally removed line in :h 'ignorecase' (#25651)zeertzjq2023-10-15
| |
| * vim-patch:2bbd0d30eebd (#25637)zeertzjq2023-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime(doc): Improve command-line completion docs (vim/vim#13331) * Improve command-line completion docs Add more details about 'ignorecase' and its effect on cmdline completion. Make sure keys used in wildmenu are properly documented and linked in the keys' documentation entries, and in `:h index` for proper cross-referencing, as wildmenu popup is slightly different from insert-mode popup menu. * Fix docs typos https://github.com/vim/vim/commit/2bbd0d30eebdea66c0da3895e83d999ed6ad83fb Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
| * vim-patch:9.0.2009: cmdline-completion for comma-separated options wrong ↵zeertzjq2023-10-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#25569) Problem: cmdline-completion for comma-separated options wrong Solution: Fix command-line expansions for options with filenames with commas Fix command-line expansions for options with filenames with commas Cmdline expansion for option values that take a comma-separated list of file names is currently not handling file names with commas as the commas are not escaped. For such options, the commas in file names need to be escaped (to differentiate from a comma that delimit the list items). The escaped comma is unescaped in `copy_option_part()` during option parsing. Fix as follows: - Cmdline completion for option values with comma-separated file/folder names will not start a new match when seeing `\\,` and will instead consider it as one value. - File/folder regex matching will strip the `\\` when seeing `\\,` to make sure it can match the correct files/folders. - The expanded value will escape `,` with `\\,`, similar to how spaces are escaped to make sure the option value is correct on the cmdline. This fix also takes into account the fact that Win32 Vim handles file name escaping differently. Typing '\,' for a file name results in it being handled literally but in other platforms '\,' is interpreted as a simple ',' and commas need to be escaped using '\\,' instead. Also, make sure this new logic only applies to comma-separated options like 'path'. Non-list options like 'set makeprg=<Tab>' and regular ex commands like `:edit <Tab>` do not require escaping and will continue to work. Also fix up documentation to be clearer. The original docs are slightly misleading in how it discusses triple slashes for 'tags'. closes: vim/vim#13303 related: vim/vim#13301 https://github.com/vim/vim/commit/54844857fd6933fa4f6678e47610c4b9c9f7a091 Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
| * fix(path): restore space separation in 'path' (#25571)zeertzjq2023-10-10
| | | | | | Removing this behavior causes more inconsistencies and bugs.
| * docs: miscellaneous doc and type fixes (#25554)Maria José Solano2023-10-10
| |
| * fix: gf fails on "foo/bar.txt:1:2" on WindowsLeonardo Mello2023-10-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: On Windows, "gf" fails on a filepath that has a line:column suffix. Example: E447: Can't find file "src/app/core/services/identity/identity.service.ts:64:23" Solution: - Remove ":" from 'isfname' on Windows. Colon is not a valid filename character (except for the drive-letter). - Handle drive letters specially in file_name_in_line(). Fixes #25160
| * vim-patch:20f48d5b2ddbzeertzjq2023-10-03
| | | | | | | | | | | | | | | | runtime(doc): mention how to disable folding in diff mode (vim/vim#13242) https://github.com/vim/vim/commit/20f48d5b2ddb9fdc29e83f0da6f31f895eaeab47 Co-authored-by: dundargoc <33953936+dundargoc@users.noreply.github.com>
| * vim-patch:9.0.1958: cannot complete option valueszeertzjq2023-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: cannot complete option values Solution: Add completion functions for several options Add cmdline tab-completion for setting string options Add tab-completion for setting string options on the cmdline using `:set=` (along with `:set+=` and `:set-=`). The existing tab completion for setting options currently only works when nothing is typed yet, and it only fills in with the existing value, e.g. when the user does `:set diffopt=<Tab>` it will be completed to `set diffopt=internal,filler,closeoff` and nothing else. This isn't too useful as a user usually wants auto-complete to suggest all the possible values, such as 'iblank', or 'algorithm:patience'. For set= and set+=, this adds a new optional callback function for each option that can be invoked when doing completion. This allows for each option to have control over how completion works. For example, in 'diffopt', it will suggest the default enumeration, but if `algorithm:` is selected, it will further suggest different algorithm types like 'meyers' and 'patience'. When using set=, the existing option value will be filled in as the first choice to preserve the existing behavior. When using set+= this won't happen as it doesn't make sense. For flag list options (e.g. 'mouse' and 'guioptions'), completion will take into account existing typed values (and in the case of set+=, the existing option value) to make sure it doesn't suggest duplicates. For set-=, there is a new `ExpandSettingSubtract` function which will handle flag list and comma-separated options smartly, by only suggesting values that currently exist in the option. Note that Vim has some existing code that adds special handling for 'filetype', 'syntax', and misc dir options like 'backupdir'. This change preserves them as they already work, instead of converting to the new callback API for each option. closes: vim/vim#13182 https://github.com/vim/vim/commit/900894b09a95398dfc75599e9f0aa2ea25723384 Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
| * vim-patch:5277cfaf8afe (#25397)zeertzjq2023-09-28
| | | | | | | | | | runtime(doc): mention mouse scrolling in scrollbind-quickadj (vim/vim#13190) https://github.com/vim/vim/commit/5277cfaf8afe847b7d4dcde6057fbecb001ab64e
| * refactor(options)!: graduate some more shortmess flagsbfredl2023-09-25
| | | | | | | | | | | | | | | | A lot of updated places in the docs were already incorrect since long since they did not reflect the default behaviour. "[dos format]" could've been argued being better for discoverability but that ship has already sailed as it is no longer displayed by default.
| * docs: remove "f" from default 'shortmess' valueGregory Anders2023-09-24
| | | | | | | | | | | | | | The "f" flag was removed in f7da4722570617bd8927e7aa533fa9a608c45bba. The value of the "f" flag is no longer listed in the 'shortmess' description and it cannot be disabled, so having it in the default value is pointless and confusing.
| * fix(ui): always use stl/stlnc fillchars when drawing statusline (#25267)tj-moody2023-09-24
| |
| * refactor(options)!: graduate shortmess+=f flagbfredl2023-09-23
| | | | | | | | | | | | | | Not everything needs to be crazy overconfigurable. Also fixes a warning in latest clang which didn't approve of the funky math switch statement in append_arg_number
| * vim-patch:9.0.1921: not possible to use the jumplist like a stack (#25278)zeertzjq2023-09-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: not possible to use the jumplist like a stack Solution: Add the 'jumpoptions' setting to make the jumplist a stack. Add an option for using jumplist like tag stack related: vim/vim#7738 closes: vim/vim#13134 ported from NeoVim: - https://neovim.io/doc/user/motion.html#jumplist-stack - neovim/neovim@39094b3 - https://vi.stackexchange.com/questions/18344/how-to-change-jumplist-behavior Based on the feedback in the previous PR, it looks like many people like this option. https://github.com/vim/vim/commit/87018255e3ad0f4dfa03e20318836d24af721caf Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com> Co-authored-by: butwerenotthereyet <58348703+butwerenotthereyet@users.noreply.github.com>
| * docs: misc #24561Justin M. Keyes2023-09-20
| | | | | | | | fix #24699 fix #25253
| * docs: replace <pre> with ``` (#25136)Gregory Anders2023-09-14
| |
| * docs: fix typos and other small fixes (#25005)dundargoc2023-09-14
| | | | | | | | | | | | | | Co-authored-by: nuid64 <lvkuzvesov@proton.me> Co-authored-by: Mike Smith <10135646+mikesmithgh@users.noreply.github.com> Co-authored-by: XTY <xty@xty.io> Co-authored-by: Empa <emanuel@empa.xyz> Co-authored-by: kyu08 <49891479+kyu08@users.noreply.github.com>
| * vim-patch:596ad66d1ddb (#25102)zeertzjq2023-09-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | runtime(doc): documentation updates This is a collection of various improvements to the help pages closes vim/vim#12790 https://github.com/vim/vim/commit/596ad66d1ddb742ef349e98eb06b8e4052f68f51 Co-authored-by: Christian Brabandt <cb@256bit.org> Co-authored-by: Houl <anwoku@yahoo.de> Co-authored-by: Doug Kearns <dougkearns@gmail.com> Co-authored-by: Adri Verhoef <a3@a3.xs4all.nl>
| * docs: various clarifications (#24876)zeertzjq2023-08-26
| |
| * vim-patch:9.0.1710: scrolloff options work slightly differentzeertzjq2023-08-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: sidescrolloff and scrolloff options work slightly different than other global-local options Solution: Make it behave consistent for all global-local options It was noticed, that sidescrolloff and scrolloff options behave differently in comparison to other global-local window options like 'listchars' So make those two behave like other global-local options. Also add some extra documentation for a few special local-window options. Add a few tests to make sure all global-local window options behave similar closes: vim/vim#12956 closes: vim/vim#12643 https://github.com/vim/vim/commit/4a8eb6e7a9df10f79bf95301ced012f0d6a13088 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * feat(defaults): treat "•" as a list item prefix #24623Justin M. Keyes2023-08-09
| | | | | | | | | | | | | | | | Problem: Nvim docs use "•" as a list item prefix but `gw{motion}` doesn't format such lists by default. Solution: Change the 'comments' option to include "fb:•" by default.
| * docs(options): fix mistakes (#24568)zeertzjq2023-08-05
| |
| * docs(options): take ownership of options.txt (#24528)Lewis Russell2023-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * docs(options): take ownership of options.txt - `src/nvim/options.lua` is now the source of truth - generate runtime/lua/vim/_meta/options.lua * fixup! zeer comments * fixup! zeer comments (2) * fixup! re-enable luacheck * fixup! regen
| * docs: remove trailing spaces #24455ii142023-07-25
| |
| * feat(options)!: remove compatible behaviours for vim 5.0 and earlierLewis Russell2023-07-17
| |
| * fix(docs): ignore_invalid #24174Justin M. Keyes2023-06-27
| | | | | | Regex bug in scripts/gen_help_html.lua:ignore_invalid()
| * fix(docs): vimdoc syntax errorsJustin M. Keyes2023-06-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prepare for https://github.com/neovim/tree-sitter-vimdoc/pull/108 which improves `{arg}` highlighting in many common cases: vim.foo({bar}) vim.foo( {bar}) nvim_foo({bar}) nvim_foo({bar},{baz}) nvim_foo({bar}, {baz}) foo[{buf}] The tradeoff is that things like `"[{"` are flagged as parse errors. We could avoid if we drop support for `foo[{buf}]`, but that is rather common (see `builtin.txt`).
| * fix(docs): vimdoc syntax errorsJustin M. Keyes2023-06-25
| | | | | | | | gen_help_html: truncate parse-error sample text
| * fix(docs): vimdoc syntax errorsJustin M. Keyes2023-06-22
| | | | | | | | | | | | Since https://github.com/neovim/tree-sitter-vimdoc/pull/97 the many cases of *.foo cause parser errors. But even before that, these were erroneously highlighted as (argument), so fixing them is good.
| * docs #24061Justin M. Keyes2023-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - nvim requires rpc responses in reverse order. https://github.com/neovim/neovim/issues/19932 - NVIM_APPNAME: UIs normally should NOT set this. ref #23520 fix #24050 fix #23660 fix #23353 fix #23337 fix #22213 fix #19161 fix #18088 fix #20693
| * vim-patch:f1dcd14fc5d4 (#23986)zeertzjq2023-06-11
| | | | | | | | | | | | | | | | | | Update runtime files https://github.com/vim/vim/commit/f1dcd14fc5d4370476cd82895a4479ca2d252e54 :autocmd-block is N/A (Vim9 script) Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * vim-patch:10e8ff9b2607 (#23977)Sean Dewar2023-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Update runtime files https://github.com/vim/vim/commit/10e8ff9b26078994cae57c2422b145d37aaf714e Also: - fix a missing `<` in builtin.txt. - edit `:function` `{name}` wording to match the change made for the docs above by Justin in #10619. - link to `*vimrc*` rather than `*init.vim*` in repeat.txt change (as `init.lua` may also be used). Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * refactor(defaults): do not use C specific default values for options (#22500)Gregory Anders2023-06-06
| | | | | | | | | | | | | | | | | | | | The options 'path', 'include', and 'define' all use C-specific default values. This may have made sense a long time ago when Vim was mostly used just for writing C, but this is no longer the case, and we have ample support for filetype specific configuration. Make the default values of these options empty and move the C-specific values into a filetype plugin where they belong. Co-authored-by: zeertzjq <zeertzjq@outlook.com>
| * defaults: shortmess+=C #23907Justin M. Keyes2023-06-05
| | | | | | | | | | | | | | | | | | Problem: Completion messages such as "scanning tags" are noisy and generally not useful on most systems. Most users probably aren't aware that this is configurable. Solution: Set `shortmess+=C`.
| * feat(term): enable reflow by default (#21124)Christian Clason2023-05-24
| | | | | | | | | | | | | | | | | | libvterm v0.3 supports reflow of terminal buffer when Nvim is resized Since v0.3 is now a required dependency, enable it by default to find (and fix) possible issues. Note: Neovim's scrollback buffer does not support reflow (yet), so lines vanishing into the buffer due to a too small window will be restored without reflow.
| * vim-patch:b7398fe41c9e (#23627)Christian Clason2023-05-15
| | | | | | | | | | | | | | Update runtime files https://github.com/vim/vim/commit/b7398fe41c9e1e731d058105a34158871ee83e3f Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * docs: small fixesdundargoc2023-05-13
| | | | | | | | | | | | | | | | | | Co-authored-by: Christian Clason <c.clason@uni-graz.at> Co-authored-by: Gregory Anders <greg@gpanders.com> Co-authored-by: HiPhish <hiphish@posteo.de> Co-authored-by: Julio B <julio.bacel@gmail.com> Co-authored-by: T727 <74924917+T-727@users.noreply.github.com> Co-authored-by: camoz <camoz@users.noreply.github.com> Co-authored-by: champignoom <66909116+champignoom@users.noreply.github.com>
| * vim-patch:9.0.1546: some commands for opening a file don't use 'switchbuf' ↵zeertzjq2023-05-13
| | | | | | | | | | | | | | | | | | | | | | (#23600) Problem: Some commands for opening a file don't use 'switchbuf'. Solution: Use 'switchbuf' for more commands. (Yegappan Lakshmanan, closes vim/vim#12383, closes vim/vim#12381) https://github.com/vim/vim/commit/54be5fb382d2bf25fd1b17ddab8b21f599019b81 Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
| * refactor: using a different error number for 'mousescroll'zeertzjq2023-05-05
| | | | | | | | Because E548 is linked to 'guicursor' in help.