fix(tui): move $COLORTERM check to _defaults.lua (#29197)
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.
(cherry picked from commit d7651b27d5)
Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
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).
(cherry picked from commit 43581011e4)
Co-authored-by: jdrouhard <john@drouhard.dev>
Problem: When an lsp client is stopped, the client will
only clear the diagnostics for the attached buffers but
not the unattached buffers.
Solution: Reset the diagnostics for the whole namespace rather than
for only the attached buffers.
(cherry picked from commit 025c874415)
Co-authored-by: crwebb85 <51029315+crwebb85@users.noreply.github.com>
Problem: if on_lines is called before the LSP is initialized, the buffer
is detached.
Solution: check for uninitialized clients before detaching.
(cherry picked from commit 292365fa1b)
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
fix(lsp): handle nil root_dir in health check (#29007)
The root directory could show up as something like:
Root directory: ~/path/to/cwd/v:null
Despite being `nil`
(cherry picked from commit f03b1622ad)
Co-authored-by: Mathias Fußenegger <mfussenegger@users.noreply.github.com>
feat(lsp): update LSP healthcheck format (#28980)
This is mostly an aesthetic change, although there are a few new pieces
of information included. Originally I wanted to investigate including
server capabilities in the healthcheck, but until we have the ability to
fold/unfold text in health checks that would be too much information.
(cherry picked from commit 5d26934c7c)
Co-authored-by: Gregory Anders <8965202+gpanders@users.noreply.github.com>
The new default SwapExists autocommand displays warning text (W325) but
does not use the WarningMsg highlight group as other warnings do. Use
the WARN log level when displaying this warning.
(cherry picked from commit e71713ba2b)
fix(comment): fall back to using trimmed comment markers (#28938)
Problem: Currently comment detection, addition, and removal are done
by matching 'commentstring' exactly. This has the downside when users
want to add comment markers with space (like with `-- %s`
commentstring) but also be able to uncomment lines that do not contain
space (like `--aaa`).
Solution: Use the following approach:
- Line is commented if it matches 'commentstring' with trimmed parts.
- Adding comment is 100% relying on 'commentstring' parts (as is now).
- Removing comment is first trying exact 'commentstring' parts with
fallback on trying its trimmed parts.
(cherry picked from commit 0a2218f965)
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem: The changetracking state can de-sync when reloading a buffer
with more than one LSP client attached.
Solution: Fully detach all clients from the buffer to force buf_state to
be re-created.
(cherry picked from commit 879d17ea8d)
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
Problem: layout i.e. whitespace that is part of codelenses is currently
displayed as weird symbols and large amounts of spaces
Solution: replace all consecutive whitespace symbols with a single space
character when trying to display codelenses as virtual text
(cherry picked from commit d9a2acdab3)
Co-authored-by: Mango The Fourth <40720523+MangoIV@users.noreply.github.com>
Problem:
vim.fs.normalize() normalizes too much vim.loader and is slow.
Solution:
Make it faster by doing less. This reduces the times spent in
vim.fs.normalize in vim.loader from ~13ms -> 1-2ms.
Numbers from a relative benchmark:
- Skipping `vim.validate()`: 285ms -> 230ms
- Skipping `path_resolve_dot()`: 285ms -> 60ms
- Skipping `double_slash`: 60ms -> 35ms
Re-normalizing a path after a `joinpath` isn't necessary. Calling
`normalize` on each child directory had quite a bit of impact when
traversing a large directory.
A simple test showed:
Before: ~144ms
After: ~80ms
running the following logic against a dir with 4367 child folders and
25826 files:
local files = {}
local start = uv.hrtime()
for name, type in vim.fs.dir(path, { depth = max_depth }) do
table.insert(files, { name, type })
end
local duration = uv.hrtime() - start
Relates to https://github.com/neovim/neovim/issues/23291
Problem: The column width 10 for parser name (lang) is too short.
For example, `markdown_inline` has 15 characters, which results in a
slight misalignment with other lines.
e.g. it looked like:
```
- OK Parser: markdown ABI: 14, path: .../parser/markdown.so
- OK Parser: markdown_inline ABI: 14, path: .../parser/markdown_inline.so
- OK Parser: php ABI: 14, path: .../parser/php.so
```
Solution: Use column width 20. As of now, the longest name among those
available in nvim-treesitter has length 18 (`haskell_persistent`).
e.g.:
```
- OK Parser: markdown ABI: 14, path: .../parser/markdown.so
- OK Parser: markdown_inline ABI: 14, path: .../parser/markdown_inline.so
- OK Parser: php ABI: 14, path: .../parser/php.so
```
Problem:
The nvim_win_xx_ns function family introduced in ba0370b1d7
needs more bake-time. Currently it's narrowly defined for windows, but
other scopes ("buffer") and features are likely in the future.
Solution:
- Rename the API with double-underscore to mark it as EXPERIMENTAL.
TODO/FUTURE:
- Rename and change the signature to support more than just "window"
scope, and for other flexibility.
- Open question: we could choose either:
- "store scopes on namespaces", or
- "store namespaces on scopes (w:/b:/…)"
Problem: filetype: zsh module files are not recognized
Solution: Detect '*.mdh' and '*.epro' as C filetype, '*.mdd' as zsh
filetype, determine zsh-modules '*.pro' from from it's content
(Wu, Zhenyu)
closes: vim/vim#14737887a38cee7
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem:
The file watcher backends for Linux have too many limitations and
doesn't work reliably.
Solution:
disable didChangeWatchedFiles on Linux
Ref: #27807, #28058, #23291, #26520
Rename the field `result` to `params` in the `data` table for
`LspProgress` autocmds. This aligns with LspNotify.
The previous name was chosen because the initial handler implementation
mistakenly had a parameter name `result` instead of `params` for the
`$/progress` LSP "notification" handler. However, `params` would be a
more appropriate name that is more consistent with the underlying LSP
type (`ProgressParams`).
See also: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#progress
