aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* fix(tui): move $COLORTERM check to _defaults.lua (#29197)Gregory Anders2024-06-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently check $COLORTERM in the TUI process to determine if the terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor" or "24bit" then we automatically assume that the terminal supports truecolor, but if $COLORTERM is set to any other value we still query the terminal. The `rgb` flag of the UI struct is a boolean which only indicates whether the UI supports truecolor, but does not have a 3rd state that we can use to represent "we don't know if the UI supports truecolor". We currently use `rgb=false` to represent this "we don't know" state, and we use XTGETTCAP and DECRQSS queries to determine at runtime if the terminal supports truecolor. However, if $COLORTERM is set to a value besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear indication that the terminal _does not_ support truecolor, so it is incorrect to treat `rgb=false` as "we don't know" in that case. Instead, in the TUI process we only check for the terminfo capabilities. This must be done in the TUI process because we do not have access to this information in the core Neovim process when `_defaults.lua` runs. If the TUI cannot determine truecolor support from terminfo alone, we set `rgb=false` to indicate "we don't know if the terminal supports truecolor yet, keep checking". When we get to `_defaults.lua`, we can then check $COLORTERM and only query the terminal if it is unset. This means that users can explicitly opt out of truecolor determination by setting `COLORTERM=256` (or similar) in their environment.
* fix(lua): don't clamp -1 or v:maxcol in vim.highlight.range() (#29203)zeertzjq2024-06-05
|
* Merge pull request #29200 from zeertzjq/vim-9.1.0463zeertzjq2024-06-05
|\ | | | | vim-patch:9.1.{0463,0466}
| * vim-patch:9.1.0466: Missing comments for fuzzy completionzeertzjq2024-06-05
| | | | | | | | | | | | | | | | | | | | | | | | Problem: Missing comments for fuzzy completion (after 9.1.0463) Solution: Add more comments, adjust indentation slightly (glepnir) closes: vim/vim#14910 https://github.com/vim/vim/commit/dca57fb54200530a0874c90fab799a689c00c597 Co-authored-by: glepnir <glephunter@gmail.com>
| * vim-patch:2a2c4ff: runtime(doc): clarify how fuzzy 'completeopt' should workzeertzjq2024-06-05
| | | | | | | | | | | | | | | | related: vim/vim#14912 https://github.com/vim/vim/commit/2a2c4fffd7e04f74b316209404767f128684a9e1 Co-authored-by: Christian Brabandt <cb@256bit.org>
| * vim-patch:9.1.0463: no fuzzy-matching support for insert-completionzeertzjq2024-06-05
|/ | | | | | | | | | | | Problem: no fuzzy-matching support for insert-completion Solution: enable insert-mode completion with fuzzy-matching using :set completopt+=fuzzy (glepnir). closes: vim/vim#14878 https://github.com/vim/vim/commit/a218cc6cdabae1113647b817c4eefc2b60a6902f Co-authored-by: glepnir <glephunter@gmail.com>
* fix(diagnostic): fix float scope filtering (#29134)Andre Toerien2024-06-04
|
* vim-patch:98b73eb: runtime(netrw): prevent accidental data lossChristian Clason2024-06-04
| | | | | | | | fixes: vim/vim#14915 https://github.com/vim/vim/commit/98b73eb645b68b6e197b63bbbae777b388d47612 Co-authored-by: Christian Brabandt <cb@256bit.org>
* fix(lsp): check if buffer is valid before LspDetach autocmd (#29162)Saltaformajo2024-06-04
|
* fix(lsp): remove superfluous on_detach callback from semantic tokens module ↵jdrouhard2024-06-04
| | | | | | | | | | | | (#29174) LspDetach is now triggered by the main on_detach callback that is added when an LSP client is attached to a buffer. The semantic_tokens module already includes a LspDetach handler that does the right thing. When the LspDetach trigger was added to the main LSP on_detach, it created a race condition in semantic tokens when a buffer was deleted that would trigger both its own on_detach and the LspDetach handlers. If the former came last, an error was thrown trying to delete a non-existent augroup (destroy() was being called twice).
* fix(lsp): account for changedtick version gap on modified reset (#29170)Mathias Fußenegger2024-06-04
| | | | Follow up to https://github.com/neovim/neovim/pull/28943 Fixes https://github.com/neovim/neovim/issues/29163
* fix(ui): superfluous showmode / excessive grid_cursor_goto #29089luukvbaal2024-06-04
| | | | | | | | | Problem: Unsetting global variables earlier in #28578 to avoid recursiveness, caused superfluous or even unlimited showmode(). Solution: Partly revert #28578 so that the globals are unset at the end of showmode(), and avoid recursiveness for ext UI by adding a recursive function guard to each generated UI call that may call a Lua callback.
* refactor(lua): use tuple syntax everywhere #29111Ilia Choly2024-06-04
|
* feat(install): mention standard paths, XDG vars in Windows installer #29101Luis Calle2024-06-04
| | | | | | | | | fix #25207 The `.wxs` files were copied from - cmake repo (BSD 3-Clause License) https://github.com/Kitware/CMake/blob/master/Utilities/Release/WiX/install_dir.wxs - wix repo [Microsoft Reciprocal License](https://github.com/wixtoolset/wix3/blob/b40e9a32c24033e11b77baf2c91a704382f898ed/LICENSE.TXT)) https://github.com/wixtoolset/wix3/blob/b40e9a32c24033e11b77baf2c91a704382f898ed/src/ext/UIExtension/wixlib/WixUI_InstallDir.wxs
* fix(runtime): remove obsolete ftplugin/calender.luaChristian Clason2024-06-04
|
* refactor(spell.c): reduce scope of localsLewis Russell2024-06-04
|
* fix(filetype): fix typos in filetype detectionEvgeni Chasnovski2024-06-04
|
* fixup: include nvim/ascii_defs.hJames Tirta Halim2024-06-04
|
* fixup: apply the change on more filesJames Tirta Halim2024-06-04
|
* fixup: LNULJames Tirta Halim2024-06-04
|
* refactor: replace '\0' with NULJames Tirta Halim2024-06-04
|
* vim-patch:9.1.0464: no whitespace padding in commentstring option in ftpluginsChristian Clason2024-06-04
| | | | | | | | | | | | | Problem: no whitespace padding in commentstring option in ftplugins Solution: Change default to include whitespace padding, update existing filetype plugins with the new default value (Riley Bruins) closes: vim/vim#14843 https://github.com/vim/vim/commit/0a0830624a260660c7fa692ecb7e6e5de09114ba Co-authored-by: Riley Bruins <ribru17@hotmail.com>
* vim-patch:partial:8.2.3637: typos in test files (#29172)zeertzjq2024-06-04
| | | | | | | | Problem: Typos in test files. Solution: Correct the typos. (Dominique Pellé, closes vim/vim#9175) https://github.com/vim/vim/commit/923dce2b07ff185c0ef661f3eca47bc17655f01b Co-authored-by: Dominique Pelle <dominique.pelle@gmail.com>
* fix(lsp): use client.id instead of pairs index (#29143)ippachi2024-06-03
| | | | | | | Problem: Completion side effects not working randomly. Solution: When creating the table of LSP responses, the table index was used, but this is not the same as the actual client_id, so it was changed to use the client_id directly.
* fix(gx): allow `@` in urldundargoc2024-06-03
| | | | | This will make `gx` work for links for the form https://hachyderm.io/@neovim.
* feat(ftplugin): change 'commentstring' to `// %s` for C/C++ (#29085)Soham Shanbhag2024-06-03
| | | | | | | | | Problem: The default commentstring for C/C++ can lead to invalid code when commenting and does not match the Nvim codebase. Solution: Change commentstring to `// %s` as used by Neovim. Also set all commentstrings that derive from the default C string explicitly (and correctly).
* vim-patch:partial:9.1.0461: too many strlen() calls in drawline.c (#29150)zeertzjq2024-06-03
| | | | | | | | | | | Problem: too many strlen() calls in drawline.c Solution: Refactor code to avoid strlen() (John Marriott) closes: vim/vim#14890 https://github.com/vim/vim/commit/f51ff96532ab8f97f779b44d17dccdda9d8ce566 Co-authored-by: John Marriott <basilisk@internode.on.net>
* vim-patch:9.1.0458: Coverity complains about division by zero (#29149)zeertzjq2024-06-03
| | | | | | | | | | | Problem: Coverity complains about division by zero Solution: Check explicitly for sw_val being zero Shouldn't happen, since tabstop value should always be larger than zero. So just add this as a safety measure. https://github.com/vim/vim/commit/7737ce519b9cba8ef135154d76b69f715b1a0b4d Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:9.1.0460: filetype: lintstagedrc files are not recognizedChristian Clason2024-06-02
| | | | | | | | | | | | | | Problem: filetype: lintstagedrc files are not recognized Solution: recognize '.lintstagedrc' files as json filetype (İlyas Akın) see: https://github.com/lint-staged/lint-staged closes: vim/vim#14897 https://github.com/vim/vim/commit/7577afd5efd0f7ebf0dbbca09713185024263ed7 Co-authored-by: İlyas Akın <ilyas.akin@kuika.com>
* Merge pull request #29124 from bfredl/inputringbfredl2024-06-02
|\ | | | | refactor(input): don't use a ring for input
| * refactor(input): don't use a ring for inputbfredl2024-06-01
| | | | | | | | Since paste data is handled via a separate channel, the data processed via `input_buffer` is typically just explicit keys as typed in by the user. Therefore it should be fine to use `memmove()` to always put the remaining data in front when refilling the buffer.
* | fix(lsp): trim trailing whitespace from completion words (#29122)Mathias Fußenegger2024-06-02
| | | | | | | | | | the `complete()` mechanism doesn't play nicely with trailing newlines or tabs. A newline causes it to insert a null character, showing up as `^@`.
* | Merge pull request #29136 from zeertzjq/vim-8.2.0083zeertzjq2024-06-02
|\ \ | | | | | | vim-patch:8.2.{0083,0109}
| * | test: add a test for #29119zeertzjq2024-06-02
| | |
| * | vim-patch:8.2.0109: corrupted text properties when expanding spaceszeertzjq2024-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Corrupted text properties when expanding spaces. Solution: Reallocate the line. (Nobuhiro Takasaki, closes vim/vim#5457) https://github.com/vim/vim/commit/ac15fd8c6761763c8feedef1a2fbd8309f0a823c Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * | vim-patch:8.2.0083: text properties wrong when tabs and spaces are exchangedzeertzjq2024-06-02
|/ / | | | | | | | | | | | | | | | | | | Problem: Text properties wrong when tabs and spaces are exchanged. Solution: Take text properties into account. (Nobuhiro Takasaki, closes vim/vim#5427) https://github.com/vim/vim/commit/5cb0b93d52fa5c12ca50a18509947ee6459bb7a8 Co-authored-by: Bram Moolenaar <Bram@vim.org>
* | Merge pull request #29132 from zeertzjq/vim-9.1.0456zeertzjq2024-06-02
|\ \ | | | | | | vim-patch:8.2.{4436,4437,4452},9.1.0456
| * | vim-patch:9.1.0456: Left shift is incorrect with vartabstop and shiftwidth=0zeertzjq2024-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Left shift is incorrect with vartabstop and shiftwidth=0 Solution: make tabstop_at() function aware of shift direction (Gary Johnson) The problem was that with 'vartabstop' set and 'shiftwidth' equal 0, left shifts using << were shifting the line to the wrong column. The tabstop to the right of the first character in the line was being used as the shift amount instead of the tabstop to the left of that first character. The reason was that the tabstop_at() function always returned the value of the tabstop to the right of the given column and was not accounting for the direction of the shift. The solution was to make tabstop_at() aware of the direction of the shift and to choose the tabtop accordingly. A test was added to check this behavior and make sure it doesn't regress. While at it, also fix a few indentation/alignment issues. fixes: vim/vim#14864 closes: vim/vim#14887 https://github.com/vim/vim/commit/88d4f255b7b7a19bb4f6489e0ad0956e47d51fed Co-authored-by: Gary Johnson <garyjohn@spocom.com>
| * | vim-patch:8.2.4452: test for what 8.2.4436 fixes does not check for regressionzeertzjq2024-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Test for what 8.2.4436 fixes does not check for regression. Solution: Set several options. (Ken Takata, closes vim/vim#9830) https://github.com/vim/vim/commit/2dada73a4ebffe2582af472ce362abd3116b58c9 Co-authored-by: Bram Moolenaar <Bram@vim.org>
| * | vim-patch:8.2.4437: vartabs test fails on MS-Windowszeertzjq2024-06-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Vartabs test fails on MS-Windows. Solution: Use iso8859-1 'encoding'. (Ken Takata, closes vim/vim#9818) https://github.com/vim/vim/commit/0f113e4f7b698fc94c1a8377afdb7249329beaee Co-authored-by: K.Takata <kentkt@csc.jp>
| * | vim-patch:8.2.4436: crash with weird 'vartabstop' valuezeertzjq2024-06-02
|/ / | | | | | | | | | | | | | | | | | | | | Problem: Crash with weird 'vartabstop' value. Solution: Check for running into the end of the line. https://github.com/vim/vim/commit/4e889f98e95ac05d7c8bd3ee933ab4d47820fdfa Code change is N/A as it's superseded by virtual text changes. Co-authored-by: Bram Moolenaar <Bram@vim.org>
* | vim-patch:e299591: runtime(doc): clarify 'shortmess' flag "S" (#29131)zeertzjq2024-06-02
| | | | | | | | | | | | | | fixes: vim/vim#14893 https://github.com/vim/vim/commit/e299591498a20c5c587364e4df57f947dfc02897 Co-authored-by: Christian Brabandt <cb@256bit.org>
* | refactor: move shared messages to errors.h #26214Justin M. Keyes2024-06-01
| |
* | fix(luacats): allow all types inside tuplesIlia Choly2024-06-01
| |
* | fix(column): crash with 'signcolumn' set to "number" (#29003)luukvbaal2024-06-01
| | | | | | | | | | | | Problem: Numberwidth may depend on number of signs with text in the buffer and is not handled correctly for extmark signs. Solution: Move legacy sign code for changed numberwidth so that it is handled properly for legacy and extmark signs alike.
* | perf(lsp): avoid repeated table lookup in completion.enableMathias Fussenegger2024-06-01
| |
* | refactor(lsp): share completion request logic between omnifunc & triggerMathias Fussenegger2024-06-01
| |
* | perf(lsp): don't copy completion items in filter passMathias Fussenegger2024-06-01
|/
* Merge pull request #29114 from bfredl/key_bufferbfredl2024-06-01
|\ | | | | refactor(tui): use a linear buffer for buffered keys
| * refactor(tui): use a linear buffer for buffered keysbfredl2024-06-01
|/ | | | | This buffer is completely emptied every time it is read from. Thus there is no point in using a ring buffer.
generated by cgit (git 2.34.1) at 2025-06-25 23:46:45 +0000