aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
| * | vim-patch:8.2.4140: maparg() does not indicate the type of scriptzeertzjq2023-11-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: maparg() does not indicate the type of script where it was defined. Solution: Add "scriptversion". https://github.com/vim/vim/commit/a9528b39a666dbaa026320f73bae4b1628a7fe51 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * | refactor(api): simplify nvim_set_keymap shortname check (#25945)zeertzjq2023-11-09
| | |
| * | docs: list NVIM_APPNAME as env on manpage (#25935)330-1272023-11-09
| | |
| * | 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>
| * fix: flush UI state before blocking in vim.wait (#25938)Gregory Anders2023-11-08
| |
| * refactor: move defaults into separate module (#25929)Gregory Anders2023-11-08
| | | | | | | | Move default mappings and autocommands into a separate module and add comments and docstrings to document each of the defaults.
| * Merge pull request #25767 from luukvbaal/signdelbfredl2023-11-08
| |\ | | | | | | feat(extmarks): add 'invalidate' property
| | * feat(extmarks): add 'invalidate' property to extmarksLuuk van Baal2023-11-08
| | | | | | | | | | | | | | | | | | | | | | | | Problem: No way to have extmarks automatically removed when the range it is attached to is deleted. Solution: Add new 'invalidate' property that will hide a mark when the entirety of its range is deleted. When "undo_restore" is set to false, delete the mark from the buffer instead.
| * | fix(diagnostic): check if delete failed in `qf_fill_buffer()` (#25932)voidiz2023-11-08
| | | | | | | | | | | | | | | | | | | | | When the contents of a quickfix buffer are replaced, there is a chance that deletion of the previous lines fails. This ensures that we don't get stuck in an infinite loop of retrying. Fix #25402
| * | fix(job-control): make jobwait() flush UI after hiding cursor (#25927)zeertzjq2023-11-08
| | |
| * | fix(input): set termkey buffer size to read stream capacityGregory Anders2023-11-07
| | | | | | | | | | | | | | | | | | | | | This ensures that the read stream never overflows termkey's internal buffer. This only happens when a large amount of bytes are pushed into termkey at the same time, which is exactly what happens when we receive a large OSC 52 response.
| * | feat(tui): use TermResponse event for OSC responses (#25868)Gregory Anders2023-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the terminal emulator sends an OSC sequence to Nvim (as a response to another OSC sequence that was first sent by Nvim), populate the OSC sequence in the v:termresponse variable and fire the TermResponse event. The escape sequence is also included in the "data" field of the autocommand callback when the autocommand is defined in Lua. This makes use of the already documented but unimplemented TermResponse event. This event exists in Vim but is only fired when Vim receives a primary device attributes response. Fixes: https://github.com/neovim/neovim/issues/25856
| * | Merge pull request #25905 from bfredl/nested_rabbit_holesbfredl2023-11-06
| |\ \ | | |/ | |/| refactor(grid): reimplement 'rightleft' as a post-processing step
| | * refactor(grid): reimplement 'rightleft' as a post-processing stepbfredl2023-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | problem: checks for wp->w_p_rl are all over the place, making simple things like "advance column one cell" incredibly complicated. solution: always fill linebuf_char[] using an incrementing counter, and then mirror the buffer as a post-processing step This was "easier" that I first feared, because the stupid but simple workaround for things like keeping linenumbers still left-right, e.g. "mirror them and them mirror them once more" is more or less what vim did already. So let's just keep doing that.
| * | build: enable ASAN for MSVCdundargoc2023-11-05
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is enabled with ENABLE_ASAN_UBSAN like other compilers. Technically it only enables ASAN as UBSAN is not available, meaning to make the variable names fully correct we'd need to separate it into two checks: ENABLE_ASAN and ENABLE_UBSAN, but the convenience of combining them into the same flag outweighs the theoretical correctness. Also note in CONTRIBUTING.md that debug builds in ASAN is not supported. Technically it is the debug runtime that is not supported, which cmake automatically enables when using the debug build type. However, neovim can't be built with debug builds without linking to the debug runtime since the third party libraries has likely been linked to the debug runtime if it was built with debug build type. This technicality is likely uninteresting to the potential developer and it's easier to just say to use a release build type.
| * refactor: the long goodbyedundargoc2023-11-05
| | | | | | | | | | | | long is 32 bits on windows, while it is 64 bits on other architectures. This makes the type suboptimal for a codebase meant to be cross-platform. Replace it with more appropriate integer types.
| * Merge pull request #25882 from bfredl/noundobfredl2023-11-05
| |\ | | | | | | feat(extmarks): add "no_undo_restore" flag to opt out of undo-restoring
| | * feat(extmarks): add "undo_restore" flag to opt out of undo-restoringbfredl2023-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is a design goal of extmarks that they allow precise tracking of changes across undo/redo, including restore the exact positions after a do/undo or undo/redo cycle. However this behavior is not useful for all usecases. Many plugins won't keep marks around for long after text changes, but uses them more like a cache until some external source (like LSP semantic highlights) has fully updated to changed text and then will explicitly readjust/replace extmarks as needed. Add a "undo_restore" flag which is true by default (matches existing behavior) but can be set to false to opt-out of this behavior. Delete dead u_extmark_set() code.
| * | refactor: combine regexp filesdundargoc2023-11-05
| |/ | | | | | | | | | | regext_bt.c and regexp_nfa.c are inlined into regexp.c instead of included as a header. This makes developer tools like clang-tidy and clangd be able to understand the code better.
| * build: various cmake fixesdundargoc2023-11-04
| | | | | | | | | | | | | | - silence false warnings on MSVC - merge `clang-tidy` cmake target into `lintc` and remove the corresponding make target - use cmake's built-in endianness detection
| * vim-patch:9.0.2090: complete_info() skips entries with 'noselect' (#25890)zeertzjq2023-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: complete_info() skips entries with 'noselect' Solution: Check, if first entry is at original text state Unfortunately, Commit daef8c74375141974d61b85199b383017644978c introduced a regression, that when ':set completeopt+=noselect' is set and no completion item has been selected yet, it did not fill the complete_info['items'] list. This happened, because the current match item did not have the CP_ORIGINAL_TEXT flag set and then the cp->prev pointer did point to the original flag item, which caused the following while loop to not being run but being skipped instead. So when the 'noselect' is set, only start with to the previous selection item, if the initial completion item has the CP_ORIGINAL_TEXT flag set, else use the 2nd previous item instead. fixes: vim/vim#13451 closes: vim/vim#13452 https://github.com/vim/vim/commit/57f9ce1a0977da13e5923214086795ffa2d28ce1 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * fix(rpc): "grid_line" event parsing crashes (#25581)LW2023-11-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | refactor: use a more idiomatic loop to iterate over the cells There are two cases in which the following assertion would fail: ```c assert(g->icell < g->ncells); ``` 1. If `g->ncells = 0`. Update this to be legal. 2. If an EOF is reached while parsing `wrap`. In this case, the unpacker attempts to resume from `cells`, which is a bug. Create a new state for parsing `wrap`. Reference: https://neovim.io/doc/user/ui.html#ui-event-grid_line
| * refactor(grid): implement rightleftcmd as a post-processing stepbfredl2023-11-03
| | | | | | | | | | | | | | Previously, 'rightleftcmd' was implemented by having all code which would affect msg_col or output screen cells be conditional on `cmdmsg_rl`. This change removes all that and instead implements rightleft as a mirroring post-processing step.
| * build: make the vimdoc generation depend on the nvim target (#25876)Gregory Anders2023-11-02
| | | | | | | | The gen_vimdoc.py script uses the nvim executable, so the executable must be built before running the script.
| * build: use built nvim artifact to generate eval files (#25875)Gregory Anders2023-11-02
| | | | | | | | | | | | | | | | | | | | | | In cases where the generated files depend on changes to Nvim itself, generating the files with an older version of Nvim will fail because those changes are not present in the older version. For example, if a new option is added then the generator script should be run with the version of Nvim that contains the new option, or else the generation will fail. Co-authored-by: dundargoc <gocdundar@gmail.com>
| * Merge pull request #25859 from luukvbaal/extmarkdelbfredl2023-11-02
| |\ | | | | | | refactor(extmarks): extmark_del() with MarkTreeIter
| | * refactor(extmarks): extmark_del() with MarkTreeIterLuuk van Baal2023-11-01
| | |
| * | build: set char to always be signeddundargoc2023-11-01
| | | | | | | | | | | | | | | Sticking to the same convention makes it easier to reason about the code and reduces complexity.
| * | fix(startup): trigger UIEnter for the correct channel (#25860)zeertzjq2023-11-01
| | |
| * | feat(server): allow embed with listen (#25709)George Harker2023-11-01
| |/ | | | | | | | | | | connection from any channel or stdio will unblock remote_ui_wait_for_attach. Wait on stdio only if only —embed specified, if both —embed and —listen then wait on any channel.
| * fix(base64): only check padding if leftover index is set (#25854)Gregory Anders2023-10-31
| |
| * feat(stdlib): add vim.base64 module (#25843)Gregory Anders2023-10-31
| | | | | | Add base64 encode() and decode() functions to a vim.base64 module.
| * Merge pull request #25850 from famiu/refactor/option/stringbfredl2023-10-31
| |\ | | | | | | refactor(options): remove `os_doskip`
| | * refactor(options): remove `os_doskip`Famiu Haque2023-10-31
| | | | | | | | | | | | | | | | | | Problem: `os_doskip` seems to be unnecessary since everything that sets it to true also returns an error, and `errmsg` being non-`NULL` already skips most of the processing. Solution: Remove `os_doskip`.
| * | fix(terminal): keep focus when scrolling number column of another window ↵zeertzjq2023-10-31
| |/ | | | | | | (#25848)
| * fix(terminal): don't lose focus on <MouseMove> (#25845)zeertzjq2023-10-31
| |
| * refactor(options)!: unify `set_option` and `set_string_option`Famiu Haque2023-10-30
| | | | | | | | | | | | | | | | While the interfaces for setting number and boolean options are now unified by #25394, there is still a separate `set_string_option` function that is used for setting a string option. This PR removes that function and merges it with set_option. BREAKING CHANGE: `v:option_old` is now the old global value for all global-local options, instead of just string global-local options. Local value for a global-local number/boolean option is now unset when the option is set (e.g. using `:set` or `nvim_set_option_value`) without a scope, which means they now behave the same way as string options. Ref: #25672
| * docs: small fixes (#25585)dundargoc2023-10-29
| | | | | | | | Co-authored-by: tmummert <doczook@gmx.de> Co-authored-by: parikshit adhikari <parikshitadhikari@gmail.com>
| * fix(api): load buffer first on nvim_buf_set_lines (#25823)Raphael2023-10-29
| | | | | | | | Fix #22670 Fix #8659
| * fix(terminal): avoid Insert mode in Terminal buffer (#25820)zeertzjq2023-10-29
| |
| * 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:9.0.2081: smoothscroll may result in wrong cursor position (#25815)luukvbaal2023-10-29
| | | | | | | | | | | | | | | | | | | | Problem: With 'smoothscroll' set, "w_skipcol" is not reset when unsetting 'wrap'. Resulting in incorrect calculation of the cursor position. Solution: Reset "w_skipcol" when unsetting 'wrap'. fixes: vim/vim#12970 closes: vim/vim#13439 https://github.com/vim/vim/commit/1bf1bf569b96d2f9b28e0cce0968ffbf2fb80aac
| * build: bump required minimum libvterm version to 0.3.3dundargoc2023-10-28
| | | | | | | | Also add detection for libvterm patch version.
| * vim-patch:9.0.2075: TextChangedI may not always trigger (#25808)zeertzjq2023-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: TextChangedI may not always trigger Solution: trigger it in more cases: for insert/ append/change operations, and when opening a new line, fixes: vim/vim#13367 closes: vim/vim#13375 https://github.com/vim/vim/commit/4bca4897a12dfb91b3b27e3083fd5f370bd857d1 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.0.2070: [security] disallow setting env in restricted mode (#25807)zeertzjq2023-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: [security] disallow setting env in restricted mode Solution: Setting environment variables in restricted mode could potentially be used to execute shell commands. Disallow this. restricted mode: disable allow setting of environment variables Setting environment variables in restricted mode, may have some unwanted consequences. So, for example by setting $GCONV_PATH in restricted mode and then calling the iconv() function, one may be able to execute some unwanted payload, because the `iconv_open()` function internally uses the `$GCONV_PATH` variable to find its conversion data. So let's disable setting environment variables, even so this is no complete protection, since we are not clearing the existing environment. I tried a few ways but wasn't successful :( One could also argue to disable the iconv() function completely in restricted mode, but who knows what other API functions can be influenced by setting some other unrelated environment variables. So let's leave it as it is currently. closes: vim/vim#13394 See: https://huntr.com/bounties/b0a2eda1-459c-4e36-98e6-0cc7d7faccfe/ https://github.com/vim/vim/commit/6b89dd6a7257a1e2e9c7ea070b407bc4674a5118 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.0.2074: Completion menu may be wrongzeertzjq2023-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Completion menu may be wrong Solution: Check for the original direction of the completion menu, add more tests, make it work with 'noselect' completion: move in right direction when filling completion_info() When moving through the insert completion menu and switching directions, we need to make sure we start at the correct position in the list and move correctly forward/backwards through it, so that we do not skip entries and the selected item points to the correct entry in the list of completion entries generated by the completion_info() function. The general case is this: 1) CTRL-X CTRL-N, we will traverse the list starting from compl_first_match and then go forwards (using the cp->next pointer) through the list (skipping the very first entry, which has the CP_ORIGINAL_TEXT flag set (since that is the empty/non-selected entry 2) CTRL-X CTRL-P, we will traverse the list starting from compl_first_match (which now points to the last entry). The previous entry will have the CP_ORIGINAL_TEXT flag set, so we need to start traversing the list from the second prev pointer. There are in fact 2 special cases after starting the completion menu with CTRL-X: 3) CTRL-N and then going backwards by pressing CTRL-P again. compl_first_match will point to the same entry as in step 1 above, but since compl_dir_foward() has been switched by pressing CTRL-P to backwards we need to pretend to be in still in case 1 and still traverse the list in forward direction using the cp_next pointer 4) CTRL-P and then going forwards by pressing CTRL-N again. compl_first_match will point to the same entry as in step 2 above, but since compl_dir_foward() has been switched by pressing CTRL-N to forwards we need to pretend to be in still in case 2 and still traverse the list in backward direction using the cp_prev pointer For the 'noselect' case however, this is slightly different again. When going backwards, we only need to go one cp_prev pointer back. And resting of the direction works again slightly different. So we need to take the noselect option into account when deciding in which direction to iterate through the list of matches. related: vim/vim#13402 related: vim/vim#12971 closes: vim/vim#13408 https://github.com/vim/vim/commit/daef8c74375141974d61b85199b383017644978c Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.0.2068: [security] overflow in :history (#25794)zeertzjq2023-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: [security] overflow in :history Solution: Check that value fits into int The get_list_range() function, used to parse numbers for the :history and :clist command internally uses long variables to store the numbers. However function arguments are integer pointers, which can then overflow. Check that the return value from the vim_str2nr() function is not larger than INT_MAX and if yes, bail out with an error. I guess nobody uses a cmdline/clist history that needs so many entries... (famous last words). It is only a moderate vulnerability, so impact should be low. Github Advisory: https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm https://github.com/vim/vim/commit/9198c1f2b1ddecde22af918541e0de2a32f0f45a N/A patch: vim-patch:9.0.2073: typo in quickfix.c comments Co-authored-by: Christian Brabandt <cb@256bit.org>
| * fix(float): win_get_bordertext_col returning negative column number (#25752)nwounkn2023-10-26
| | | | | | | | | | | | | | | | Problem: `win_get_bordertext_col` returns column < 1 for right or center aligned text, if its length is more than window width. Solution: Return max(resulting_column, 1)
| * vim-patch:9.0.2064: cannot use buffer-number for errorformat (#25782)zeertzjq2023-10-26
| | | | | | | | | | | | | | | | | | | | | | Problem: cannot use buffer-number for errorformat Solution: add support for parsing a buffer number using '%b' in 'errorformat' closes: vim/vim#13419 https://github.com/vim/vim/commit/b731800522af00fd348814d33a065b92e698afc3 Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.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>