aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* | Merge pull request #24704 from seandewar/cmdwin-madnessSean Dewar2024-01-28
|\ \ | | | | | | vim-patch:9.1.{0047,0048,0049}: fun cmdwin fixes
| * | vim-patch:9.1.0049: Make "[Command Line]" a special buffer nameSean Dewar2024-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: E95 is possible if a buffer called "[Command Line]" already exists when opening the cmdwin. This can also happen if the cmdwin's buffer could not be deleted when closing. Solution: Un-name the cmdwin buffer, and give it a special name instead, similar to what's done for quickfix buffers and for unnamed prompt and scratch buffers. As a result, BufFilePre/Post are no longer fired when opening the cmdwin. Add a "command" key to the dictionary returned by getbufinfo() to differentiate the cmdwin buffer instead. (Sean Dewar) Cherry-pick test_normal changes from v9.0.0954. https://github.com/vim/vim/commit/1fb41032060df09ca2640dc49541f11062f6dfaa
| * | vim-patch:9.1.0048: Abort opening cmdwin if autocmds screw things upSean Dewar2024-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Autocmds triggered from opening the cmdwin (in win_split and do_ecmd) can cause issues such as E199, as the current checks are insufficient. Solution: Commands executed from the cmdwin apply to the old curwin/buf, so they should be kept in a "suspended" state; abort if they've changed. Also abort if cmdwin/buf was tampered with, and check that curwin is correct. Try to clean up the cmdwin buffer (only if hidden and non-current to simplify things; the same approach is used when closing cmdwin normally), and add a beep. (Sean Dewar) Rename the old Test_cmdwin_interrupted() like in the patch (can be moved to test_cmdwin.vim when v9.0.0027 is ported). Move the error message to `e_active_window_or_buffer_changed_or_deleted`. https://github.com/vim/vim/commit/43b395ec2e7d24a067d7cb00109818b64da144a5
| * | vim-patch:9.1.0047: issues with temp curwin/buf while cmdwin is openSean Dewar2024-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Things that temporarily change/restore curwin/buf (e.g: win_execute, some autocmds) may break assumptions that curwin/buf is the cmdwin when "cmdwin_type != 0", causing issues. Solution: Expose the cmdwin's real win/buf and check that instead. Also try to ensure these variables are NULL if "cmdwin_type == 0", allowing them to be used directly in most cases without checking cmdwin_type. (Sean Dewar) Reset and save `cmdwin_old_curwin` in a similar fashion. Apply suitable changes for API functions and add Lua tests. https://github.com/vim/vim/commit/988f74311c26ea9917e84fbae608de226dba7e5f
* | | Merge pull request #27221 from BugLight/fix-coverity-found-bugszeertzjq2024-01-28
|\ \ \ | |/ / |/| | Fix bugs found by coverity
| * | fix(coverity/471380): null dereference in get_local_additions()Daniil Zhukov2024-01-27
| | | | | | | | | | | | | | | | | | | | | | | | strrchr returns null pointer if '.' is not present in file name. Notice that filenames are filtered to match "doc/*.??[tx]" pattern earlier so we shouldn't expect null pointer here. However later in code strrchr return value is checked so it seems better and more consistent to do the same here too.
| * | fix(coverity/348240): memory leak in put_view()Daniil Zhukov2024-01-26
| | |
* | | docs(lua): update ":{range}lua" docs + error message #27231Justin M. Keyes2024-01-27
| | | | | | | | | | | | | | | - `:lua (no file)` is misleading because `:lua` never takes a file arg, unlike `:source`. - Update various related docs.
* | | fix(decor): check decor kind before accessing union field (#27205)Gregory Anders2024-01-27
| |/ |/| | | | | | | | | The data.sh.url field is valid only when item.kind is kDecorKindHighlight. The `if` block just before this line already does that check (as well as checking `active`) so move the access of `data.sh.url` into that block.
* | fix(events): check for WinResized/WinScrolled in terminal mode (#27226)zeertzjq2024-01-27
| |
* | fix(api): limit depth of nvim_cmd (#27225)zeertzjq2024-01-27
| |
* | feat(ex_cmds): ranged :lua #27167luukvbaal2024-01-26
|/ | | | | | :{range}lua executes the specified lines in the current buffer as Lua code, regardless of its extension or 'filetype'. Close #27103
* fix(extmarks): do not remove decor from invalid old marksLuuk van Baal2024-01-26
|
* fix(colorscheme): typoJaehwang Jung2024-01-26
|
* vim-patch:9.1.0058: Cannot map Super Keys in GTK UI (#27204)zeertzjq2024-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Cannot map Super Keys in GTK UI (Casey Tucker) Solution: Enable Super Key mappings in GTK using <D-Key> (Casey Tucker) As a developer who works in both Mac and Linux using the same keyboard, it can be frustrating having to remember different key combinations or having to rely on system utilities to remap keys. This change allows `<D-z>` `<D-x>` `<D-c>` `<D-v>` etc. to be recognized by the `map` commands, along with the `<D-S-...>` shifted variants. ```vimrc if has('gui_gtk') nnoremap <D-z> u nnoremap <D-S-Z> <C-r> vnoremap <D-x> "+d vnoremap <D-c> "+y cnoremap <D-v> <C-R>+ inoremap <D-v> <C-o>"+gP nnoremap <D-v> "+P vnoremap <D-v> "-d"+P nnoremap <D-s> :w<CR> inoremap <D-s> <C-o>:w<CR> nnoremap <D-w> :q<CR> nnoremap <D-q> :qa<CR> nnoremap <D-t> :tabe<CR> nnoremap <D-S-T> :vs#<CR><C-w>T nnoremap <D-a> ggVG vnoremap <D-a> <ESC>ggVG inoremap <D-a> <ESC>ggVG nnoremap <D-f> / nnoremap <D-g> n nnoremap <D-S-G> N vnoremap <D-x> "+x endif ``` closes: vim/vim#12698 https://github.com/vim/vim/commit/92e90a1e102825aa9149262cacfc991264db05df Co-authored-by: Casey Tucker <dctucker@hotmail.com>
* vim-patch:9.1.0054: 'linebreak' may still apply to leading whitespacezeertzjq2024-01-26
| | | | | | | | | | | | | | Problem: 'linebreak' may still apply to leading whitespace (VanaIgr) Solution: Compare pointers instead of virtual columns. (zeertzjq) related: #27180 closes: vim/vim#13915 https://github.com/vim/vim/commit/703f9bc943a29d947869b5cb0370be2ac42d5ac9 Co-authored-by: VanaIgr <vanaigranov@gmail.com>
* fixup: raise TS min versionChristian Clason2024-01-25
|
* vim-patch:9.1.0055: formatting long lines is slow (#27199)zeertzjq2024-01-26
| | | | | | | | | | | | | | | | | Problem: formatting long lines is slow (kawaii-Code) Solution: optimize gq (internal_format) for long lines (kawaii-Code) Implemented two workarounds that significantly reduce the amount of pointless calls. Ideally the algorithm would be rewritten not to be n^2, but it's too complicated with too many corner cases. closes: vim/vim#13914 https://github.com/vim/vim/commit/78019df645400796831670ec166e7e3b55ae8310 Co-authored-by: kawaii-Code <nia.personal.0@gmail.com>
* feat(colorscheme): update treesitter groupsEvgeni Chasnovski2024-01-25
| | | | | | | | | | | | Problem: Currently default color scheme defines most of treesitter highlight groups. This might be an issue for users defining their own color scheme as it breaks the "fallback property" for some of groups. Solution: Define less default treesitter groups; just enough for default color scheme to be useful. That is: - All first level groups (`@character`, `@string`, etc.). - All `@xxx.builtin` groups as a most common subgroup. - Some special cases (links/URLs, `@diff.xxx`, etc.).
* fix(colorscheme): use explicit normal foreground in syntax groupsEvgeni Chasnovski2024-01-25
| | | | | | | | | | | | Problem: Some core syntax highlight groups are cleared with intention to always be shown without additional highlighting. This doesn't always work as intended, especially with fallback mechanism of @-groups. Example: `Statement`/`Keyword` group shown in help code blocks (`@markup.raw`) is shown as bold (from `Statement`) cyan (from `@markup.raw`) instead of bold grey. Solution: Explicitly use normal grey foreground in syntax groups where it was previously implicitly assumed.
* refactor: IWYU (#27186)zeertzjq2024-01-25
|
* docs: various fixes (#27063)dundargoc2024-01-25
| | | | | | Co-authored-by: lmenou <menl94629@gmail.com> Co-authored-by: altermo <107814000+altermo@users.noreply.github.com> Co-authored-by: VanaIgr <vanaigranov@gmail.com> Co-authored-by: Gregory Anders <greg@gpanders.com>
* feat(ui): add support for OSC 8 hyperlinks (#27109)Gregory Anders2024-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extmarks can contain URLs which can then be drawn in any supporting UI. In the TUI, for example, URLs are "drawn" by emitting the OSC 8 control sequence to the TTY. On terminals which support the OSC 8 sequence this will create clickable hyperlinks. URLs are treated as inline highlights in the decoration subsystem, so are included in the `DecorSignHighlight` structure. However, unlike other inline highlights they use allocated memory which must be freed, so they set the `ext` flag in `DecorInline` so that their lifetimes are managed along with other allocated memory like virtual text. The decoration subsystem then adds the URLs as a new highlight attribute. The highlight subsystem maintains a set of unique URLs to avoid duplicating allocations for the same string. To attach a URL to an existing highlight attribute we call `hl_add_url` which finds the URL in the set (allocating and adding it if it does not exist) and sets the `url` highlight attribute to the index of the URL in the set (using an index helps keep the size of the `HlAttrs` struct small). This has the potential to lead to an increase in highlight attributes if a URL is used over a range that contains many different highlight attributes, because now each existing attribute must be combined with the URL. In practice, however, URLs typically span a range containing a single highlight (e.g. link text in Markdown), so this is likely just a pathological edge case. When a new highlight attribute is defined with a URL it is copied to all attached UIs with the `hl_attr_define` UI event. The TUI manages its own set of URLs (just like the highlight subsystem) to minimize allocations. The TUI keeps track of which URL is "active" for the cell it is printing. If no URL is active and a cell containing a URL is printed, the opening OSC 8 sequence is emitted and that URL becomes the actively tracked URL. If the cursor is moved while in the middle of a URL span, we emit the terminating OSC sequence to prevent the hyperlink from spanning multiple lines. This does not support nested hyperlinks, but that is a rare (and, frankly, bizarre) use case. If a valid use case for nested hyperlinks ever presents itself we can address that issue then.
* build: various build improvementsdundargoc2024-01-24
| | | | | | | | | | | | | | | | | | - remove "ran-" prefix from touch files as it's redundant since the they're already in the directory named `touches`. - Include `contrib` when formatting with `make formatlua`. - Use TARGET_FILE generator expression instead of assuming the executable location. - reuse logic that determines whether to use lua or luajit. - add translations to the `nvim` target. Makefile improvements: - rename variable `CMAKE_PRG` to `CMAKE` to make it more consistent with the builtin `MAKE` variable. - stop propagating flags to generator. Users should use cmake for non-standard use cases. - remove `+` prefix from targets. If the user for whatever reason wants to dry-run a target then they should be able to.
* fix(spell): always accept ':' as filename char in 'spellfile' (#27172)zeertzjq2024-01-24
| | | Follow-up to #25236
* fix(options): use a union for def_val (#27169)zeertzjq2024-01-24
| | | | | | | | | Problem: APIs get wrong boolean option default values on big-endian platforms. Solution: Use a union for def_val. Cannot use OptVal or OptValData yet as it needs to have the same types as option variables.
* vim-patch:9.1.0046: :drop does not re-use empty buffer (#27165)zeertzjq2024-01-24
| | | | | | | | | | | | | Problem: :drop does not re-use empty buffer (Rocco Mao) Solution: Make :drop re-use an empty buffer (Rocco Mao) fixes: vim/vim#13851 closes: vim/vim#13881 https://github.com/vim/vim/commit/f96dc8d07f752ddd96d1447d85278a85255a1462 Co-authored-by: Rocco Mao <dapeng.mao@qq.com>
* fix(sign): avoid deleting from sign map while looping over it (#27158)luukvbaal2024-01-24
|
* fix(colorscheme): link LSP semantic tokens to treesitter groupsJohn Drouhard2024-01-23
|
* Merge pull request #27147 from bfredl/crash2bfredl2024-01-23
|\ | | | | fix(extmark): another "step out" case
| * fix(extmark): fix crash when stepping out from internal nodebfredl2024-01-23
| |
* | fix(treesitter): update @markup default linksChristian Clason2024-01-23
|/ | | | | | | | * use `Special` as default for `@markup.*`, especially `@markup.raw` and `@markup.math` (`@markup` itself is never used) * use `Structure` for `@markup.environment` * highlight all of `@markup.link` as Underlined (otherwise concealed links are invisible)
* fix(extmarks): crash with sign after many marksbfredl2024-01-23
| | | | fixes #27137
* vim-patch:9.1.0043: ml_get: invalid lnum when :s replaces visual selection ↵zeertzjq2024-01-23
| | | | | | | | | | | | | | | | (#27140) Problem: ml_get: invalid lnum when :s replaces visual selection (@ropery) Solution: substitute may decrement the number of lines in a buffer, so validate, that the bottom lines of the visual selection stays within the max buffer line fixes: vim/vim#13890 closes: vim/vim#13892 https://github.com/vim/vim/commit/7c71db3a58f658b4329b82ab603efa928d17bdbc Co-authored-by: Christian Brabandt <cb@256bit.org>
* fix(column): clear "b_signcols" when marktree is clearedLuuk van Baal2024-01-22
|
* perf(extmarks): add metadata for efficient filtering of special decorationsbfredl2024-01-22
| | | | | | | | | | | | | | | | | | This expands on the global "don't pay for what you don't use" rules for these special extmark decorations: - inline virtual text, which needs to be processed in plines.c when we calculate the size of text on screen - virtual lines, which are needed when calculating "filler" lines - signs, with text and/or highlights, both of which needs to be processed for the entire line already at the beginning of a line. This adds a count to each node of the marktree, for how many special marks of each kind can be found in the subtree for this node. This makes it possible to quickly skip over these extra checks, when working in regions of the buffer not containing these kind of marks, instead of before where this could just be skipped if the entire _buffer_ didn't contain such marks.
* docs(options): remove misleading sentence (#27129)zeertzjq2024-01-22
| | | | Setting 'verbose' to 1 doesn't cause Nvim to produce messages. It adds more information to existing messages, which is documented above.
* feat(fold): transparent foldtextLewis Russell2024-01-22
| | | | | | | | | | | | | | | | | 'foldtext' can be set to an empty string to disable and render the line with: - extmark highlight - syntax highlighting - search highlighting - no line wrapping - spelling - conceal - inline virtual text - respects `fillchars:fold` Currently normal virtual text is not displayed Co-authored-by: zeertzjq <zeertzjq@outlook.com>
* Merge pull request #27076 from glepnir/extmark_hlgroupbfredl2024-01-22
|\ | | | | refactor(api): use hl id directly in nvim_buf_set_extmark
| * refactor(api): give "hl_group" more accurate _meta typebfredl2024-01-22
| | | | | | | | | | These can either be number or string in lua, so we can specify this directly as "number|string".
| * refactor(api): use hl id directly in nvim_buf_set_extmarkglepnir2024-01-20
| |
* | fix(eval): properly support checking v:lua function in exists() (#27124)Raphael2024-01-22
| |
* | refactor: use "csarg" for CharsizeArg variables (#27123)zeertzjq2024-01-22
| |
* | Merge pull request #26813 from VanaIgr/screen-pos-speedupzeertzjq2024-01-22
|\ \ | | | | | | | | | | | | | | | | | | perf: make screen size and position calculations more efficient N/A patches for version.c: vim-patch:9.1.0037: Calling get_breakindent_win() repeatedly when computing virtcol vim-patch:9.1.0038: Unnecessary loop in getvcol()
| * | perf: reuse fast character size calculation algorithm from getvcol()VanaIgr2024-01-22
| | |
| * | perf: don't decode utf8 character multiple times in getvcol()VanaIgr2024-01-22
| | | | | | | | | | | | | | | | | | | | | | | | The optimized virtual column calculation loop in getvcol() was decoding the current character twice: once in ptr2cells() and the second time in utfc_ptr2len(). For combining charcters, they were decoded up to 2 times in utfc_ptr2len(). Additionally, the function used to decode the character could be further optimised.
| * | perf: remove loop for computing last position in getvcol()VanaIgr2024-01-18
| | | | | | | | | | | | | | | | | | | | | | | | The function computed the start of the multibyte character and iterated until the current character reached this position. The loop at the start of the function handed the case where the index passed to the function was past the end of the line. This loop can be removed if the function instead compares the next position against the end position end exits the loop if it is greater than the end position.
| * | perf: cache breakindent/showbreak width in win_lbr_chartabsizeVanaIgr2024-01-18
| |/ | | | | | | | | | | breakindent was recomputed on every call to win_lbr_charbabsize() when the character is past the end of the first row of a wrapped line. Even though the function for computing breakindent cached the last result, reusing the cached value required strcmp of the cached line with the given line.
* | fix(rpc): assertion failure due to invalid msgpack inputnwounkn2024-01-21
| | | | | | | | | | | | | | | | | | Problem: rbuffer_consumed assertion fails if Unpacker fails to parse msgpack, because it doesn't consume bytes on errors Solution: Call rbuffer_consumed_compact only if Unpacker isn't closed
* | build: create BINARY_LIB_DIR directory before adding parserdundargoc2024-01-22
| | | | | | | | | | | | cmake -E copy_directory behaves differently depending on if the directory in question exists or not. Always create it to ensure it behaves consistently.
generated by cgit (git 2.34.1) at 2025-06-26 10:29:15 +0000