Hyphenated language names are silently dropped when used as injections
(see #38132).
This combines the normalization of language aliases into `resolve_lang`,
and also adds the normalization of hyphens to underscores, which allows
for handling of injected language tags with hyphens in their names.
Fixes#38132.
- Use double underscores for the group targets as these targets usually
shouldn't be used directly.
- Use dash instead of underscore in the two targets that need to be used
directly. I'm not entirely sure about this, as both chars are used in
many targets, but a dash is easier to type than an underscore.
Problem: During initial "bootstrap" via lockfile synchronization, the
whole plugin specification is reconstructed from the lockfile data,
ignoring potential user changes added in the first `vim.pack.add()`.
This is enough in most situations since it is the only data needed
for actual installation.
However, this affects specification passed to `PackChanged[Pre]`
events. In particular, `data` field is missing which can be a problem
if there is a `PackChanged kind=install` hook that uses that field
(like with some kind of `build` method used during install).
And there might be different `version` set in `vim.pack.add()`.
Solution: Pass the `specs` input of the first `vim.pack.add()` down to
lockfile synchronization and use it to reconstruct plugin
specification for the to-be-installed plugin. If present among the
user's `specs`, it is used but with forced `src` from the lockfile (as
it is the one used during installation).
Note that this still has a caveat when using separate
`vim.pack.add()`, as only the specs from the first input (when the
lockfile synchronization happens) is taken into account.
Problem: nvim_win_get_config() does not return a window's "style".
Solution: always include it, and document `style=""`.
Always included so it can be used reciprocally with nvim_open_win() or
nvim_win_set_config(). (otherwise the config of a window with kWinStyleUnused
will not unset the kWinStyleMinimal style of another window if passed to
nvim_win_set_config, for example)
Problem: cannot display tabs for indentation
Solution: Add the "leadtab" value to the 'listchars' option to
distinguish between tabs used for indentation and tabs used
for alignment (HarshK97).
closes: vim/vim#190948526d32647
Co-authored-by: HarshK97 <harshkapse1234@gmail.com>
Problem: currently in the example a new diagnostic namespace is created
for showing it manually with a custom config. Because of a separate
namespace, when the original diagnostic source sets diagnostics again,
it will not affect the diagnostic shown in that new namespace and the
user would need to implement the logic for hiding it themselves,
separately as well.
Solution: instead of creating a new namespace, reuse the original
diagnostic's namespace, so once the source sets diagnostics again, it's
removed and hidden automatically without user having to do anything
extra for that.
Problem: If Nvim server fails to --listen and prints error before the
TUI enters alternate screen, the error isn't visible.
Solution: Forward server stderr using client side stderr handler instead
of having the server inherit client stderr file descriptor.
This does mean that `stderr_isatty` will be `false` in the server, but
that value doesn't matter in embedded mode.
Always pass `stdin_fd` to embedded server to avoid a hang when reading
from stdin when it's a TTY (not sure why one wants to do that, perhaps
by mistake), because if `stdin_fd` isn't passed, the server will try to
use stderr as stdin.
Example test failure on CI:
FAILED test/functional/terminal/tui_spec.lua @ 41: TUI exit status 1 and error message with server --listen error #34365
test/functional/terminal\tui_spec.lua:55: Failed to match any screen lines.
Expected (anywhere): "nvim%.exe: Failed to %-%-listen: address already in use:"
Actual:
|{114:nvim.exe -h"} |
| |
|[Process exited 1]^ |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|{5:-- TERMINAL --} |
Snapshot:
screen:expect([[
{114:nvim.exe -h"} |
|
[Process exited 1]^ |
|*13
{5:-- TERMINAL --} |
]])
stack traceback:
test\functional\ui\screen.lua:909: in function '_wait'
test\functional\ui\screen.lua:537: in function 'expect'
test/functional/terminal\tui_spec.lua:55: in function <test/functional/terminal\tui_spec.lua:41>
In this case, it appears that the client entered alternate screen in the
middle of the server's print_mainerr().
Problem:
The DSR wait warning causes any test that involves Nvim TUI to become
flaky on Windows. Example:
FAILED test/functional/terminal/cursor_spec.lua @ 367: :terminal cursor can be positioned arbitrarily
test/functional/terminal\cursor_spec.lua:377: Row 1 did not match.
Expected:
|*^ |
|*~ |
|*~ |
|*~ |
|*~ |
|* |
|{5:-- TERMINAL --} |
Actual:
|* |
|* |
|*{2: }|
|*{103:defaults.lua: Did not detect DSR response from ter}|
|*{103:minal. This results in a slower startup time. }|
|*{UNEXPECTED foreground = tonumber('0x000006'):Press ENTER or type command to continue^ }|
|{5:-- TERMINAL --} |
Solution:
Don't show the DSR wait warning when running tests.
Problem: There is a xkb syntax, but no filetype plugin.
Solution: Create a filetype plugin and set the comment and commentstring
options for the xkb filetype (xkb = X keyboard extension)
closes: vim/vim#1953714eddc7d46
Co-authored-by: GX <59413576+gx089@users.noreply.github.com>
Attempt to match all variations of group name and comma separator across
continuation lines.
Fixes issues:
- vim/vim#18491 (Two ")"s are incorrectly colored 'vimOperError' in
syntax/mail.vim), reported by @lkintact
- vim/vim#19366 (highlight error for contains elements in a new line), reported
by Maxim Kim
fixes: vim/vim#18491fixes: vim/vim#19366b901fa9a6a
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: Color completion items display as plain text without visual preview
Solution: Parse RGB/hex colors from documentation and render with colored symbol ■
Closing the quickfix window previously triggered a WinClosed autocmd
that deleted all difftool autocmds and pushed an empty quickfix list,
making the difftool non-functional. Users who close the quickfix window
to gain screen real estate for viewing diffs had no way to continue
navigating entries.
Remove the qf_win tracking and its associated WinClosed autocmd so that
closing the quickfix window no longer tears down the difftool state.
Closing either diff window still performs full cleanup as before.
The BufWinEnter handler no longer passes with_qf to diff_files, so
navigating entries while the quickfix window is closed reuses the
existing diff layout without forcing a layout rebuild.
Fixes#37388
Problem: Unable to configure message targets based on message kind.
Solution: Add cfg.msg.targets mapping message kinds to "cmd/msg/pager".
Check the configured target when writing the message.
cfg.msg = { target = 'cmd', targets = { progress = 'msg', list_cmd = 'pager' } }
will for example use the 'msg' target for progress messages,
immediately open the pager for 'list_cmd' and use the cmdline
for all other message kinds.
Patch 9.2.0033 (vim/vim#19260) introduced a dedicated `env` filetype for
.env files, which were previously detected as `sh`. This left env
files without `commentstring`, `comments`, or `formatoptions` since
no ftplugin was added alongside the new filetype.
Add runtime/ftplugin/env.vim to set these options, matching the
behavior that .env files had when they used the `sh` filetype.
closes: vim/vim#195229148644c1e
Co-authored-by: snelling-a <72226000+snelling-a@users.noreply.github.com>
Problem:
Descriptions of plugins often contain taglinks which are generally
concealed. This misaligns them by 2 characters with descriptions that
don't have a taglink in them.
Solution:
Don't count "bar" characters (`|`) for the description width.
Example:
Actual buffer content:
```
myplugin.txt |lsp| is cool
myplugin.txt this is a nice plugin
```
Rendered as:
```
myplugin.txt lsp is cool
myplugin.txt this is a nice plugin
```
Problem:
vim.fs.joinpath treats empty string as a path segment
(it adds a path separator for each empty item):
print(vim.fs.joinpath('', 'after/lsp', '')) -- '/after/lsp/'
print(vim.fs.joinpath('', '')) -- '/'
Especially problematic if the empty segment is the first segment, as
that converts the path to an absolute path.
Solution:
Ignore empty (length of 0) path segments.
Benchmark:
local function test(func)
local t = vim.uv.hrtime()
for _ = 1, 100000, 1 do
func('', 'this/is', 'a/very/long/path', '', 'it', 'really', 'is')
end
print(math.floor((vim.uv.hrtime() - t) / 1e6), 'ms')
end
- with Iter():filter() --> 370 ms
- building new segments table --> 208 ms
- with vim.tbl_filter --> 232 ms
- Instead of gsub split on `/` in all parts --> 1870 ms
Problem:
Automatic background detection sets the background option too late,
which loads colorschemes twice and causes problems when the user's
terminal background doesn't match the default (#32109, #36211, #36416).
Solution:
Use a DA1 query to determine whether the TTY supports OSC 11. Wait for
background detection and setting to complete before processing user
config.
Note: To preserve the existing behavior as much as possible, this triggers
OptionSet manually on VimEnter (since it won't trigger automatically if
we set bg during startup). However, I'm unsure if this behavior is
truly desired given that the documentation says OptionSet is triggered
"After setting an option (except during |startup|)."
Also fixes flickering issue #28667. To check for flickering:
nvim --clean --cmd "set termguicolors" --cmd "echo \"foo\"" --cmd "sleep 10"
On master, this gives me a black screen for 10 seconds, but on this
branch, the background is dark or light depending on the terminal
background (since the option is now set during startup rather than after
VimEnter).
Problem:
Regression from b99cdd0:
Pull diagnostics (from `textDocument/diagnostic`) and push diagnostics
(from `textDocument/publishDiagnostics`) use the same namespace, which
is a problem when using language servers that publish two different sets
of diagnostics on push vs pull, like rust-analyzer (see
https://github.com/rust-lang/rust-analyzer/issues/18709#issuecomment-2551394047).
Solution:
Rename `is_pull` to `pull_id` which accepts a pull namespace instead of
just a boolean.
Problem: Not possible to know when a session will be loaded.
Solution: Add the SessionLoadPre autocommand (Colin Kennedy).
fixes: vim/vim#19084closes: vim/vim#193061c0d468d72
Co-authored-by: Colin Kennedy <colinvfx@gmail.com>
Problem:
If a server is slow with catching up, there can be stale diagnostics
for deleted lines. Then if a user uses `jump` it can error like:
E5108: Lua: ...runtime/lua/vim/diagnostic.lua:670: attempt to index a nil value
stack traceback:
...runtime/lua/vim/diagnostic.lua:670: in function 'get_logical_pos'
...runtime/lua/vim/diagnostic.lua:687: in function 'diagnostic_lines'
...runtime/lua/vim/diagnostic.lua:1122: in function 'next_diagnostic'
...runtime/lua/vim/diagnostic.lua:1665: in function 'jump'
Solution:
Fallback to diagnostic location. That's better than the failure.
Problem: Timer removing a message from the msg buffer does not remove
empty lines if window is closed (col([ui.wins.msg]) fails).
Solution: Use nvim_buf_get_text() to check if line is empty.
fixes#37586
when doing `packadd mypackage` up to two exact paths are added
to &rtp. Instead of recalculating runtime_search_path from scratch,
we can "just" splice these two paths in
This is simple in theory, but get complicated in practice as
"after" dirs do exist and need some wrangling.
Echasnovski did some benchmarking, to show that this reduces overhead
of a init.lua configuration style where separate `packadd!` calls are
used spread out during the config. In addition, "batched" addition
(either using "start" packages or packadd! a lot of opt packages at
once) does not regress.
A theoretical simplification could be to NEVER explicitly add "after"
dirs to &rtp, but implicitly add all existing "after" dirs in reverse
order when calculating the effective run time path. This might be tricky
to do without breaking 12 tpope plugins again tho.
We might also instead consider solutions where &rtp remains fully expanded but no longer is the main source of truth. But this is all post 0.12 work. This PR is an alright stopgap to make 0.12 fully support intended use cases of vim.pack.add() .
Problem:
- `:args` and `argv()` can change after startup.
- `v:arg` includes options/commands, not just files.
- Plugins (e.g. Oil) may rewrite directory args.
Solution:
- New read-only var `v:argf`: snapshot of file/dir args at startup.
- Unaffected by `:args` or plugins.
- Unlike `v:argv`, excludes options/commands.
- Paths are resolved to absolute paths when possible
Example:
nvim file1.txt dir1 file2.txt
:echo v:argf
" ['/home/user/project/file1.txt', '/home/user/project/dir1', '/home/user/project/file2.txt']
Problem: - Unintentionally inserting lines for a replaced multiline
message that also has multiple highlights.
- Scheduled check to see if the expanded cmdline window was
entered makes it difficult to keep track of what happens when
the key pressed to dismiss it results in a message.
- Reading the first line of an error message should be enough
notice for something going wrong.
- "search_cmd" messages should not be shown with 0 'cmdheight'.
- Unable to configure dynamically changed pager height.
- Enabling UI2 doesn't make sense with no UIs attached.
Solution: - Only insert a line for the first chunk after a newline.
- Use getmousepos() to check if the expanded cmdline was
clicked to enter the pager.
entering the pager to serve as a configuration interface.
- Don't expand the cmdline for error messages; user can press g<.
- Don't show "search_cmd" messages with 'cmdheight' set to 0.
- Change 'eventignorewin' to ensure WinEnter is fired when
- Have enable() return early when no UIs are attached.
Problem:
:InspectTree don't show luadoc injection lua file. Since luadoc share
the same "root" with comment in their common primary (lua) tree.
Current logic simply show the largest (comment injection) and ignore all
smaller one (luadoc injection).
Solution:
Handle different lang injections separately. Then sort them by
byte_length to ensure the draw tree consistent.
Problem:
When vim._watch.watch() is used to watch a single file, libuv returns
the basename as the filename argument in the callback. The code joins
this with the watched path, producing a nonsensical path like
"/path/to/file.lua/file.lua", which causes ENOTDIR errors on
subsequent fs_stat calls.
Solution:
Check whether the watched path is a directory before joining the
filename. When watching a file, ignore the filename from libuv and
use the watched path directly.
Problem:
The html and css of the website's documentation pages are defined in
long strings in gen_help_html.lua, making it hard to maintain and
improve them. E.g. adding in headers that state the documentation is for
nightly Nvim has been a long standing feature request.
Solution:
Move the inlined css and html (e.g. the <head>, <nav>, etc.) to Hugo.
Now that the website is build with Hugo, we can use its templating
system to generate the full html/css from the Tree-sitter tree:
https://github.com/neovim/neovim.github.io/pull/437
`lsp.config[]` resolves an LSP config the first time it is called, and
returns the cached result on subsequent calls.
The change in #37571 added an extra call to `lsp.config[]` which will
resolve the config *before* the server is added to `_enabled_configs`,
meaning the result is discarded. That means configs will be needlessly
resolved again once `lsp_enable_callback` fires for the first time. That
includes an additional `loadfile()` call which is relatively expensive
and can have unexpected side effects.
Avoid this by storing the result of the initial call to `lsp.config[]`
in `_enabled_configs` so the config is not resolved a second time once
`lsp_enable_callback` is called for the first time.
Problem: after #33036, an error from evaluating 'statusline' clears it and
doesn't draw the statusline. (causing glitchy redraws)
Solution: use the default value instead. If 'stl' is somehow ever empty, still
call redraw_custom_statusline to at least draw an empty statusline.
Ideally our default 'stl' shouldn't itself error too! :-)
Also adjust some prior screen:expect()s to avoid immediate success warnings.
Problem:
- Editing a 'readonly' file forces a 3-second delay.
- nvim_get_mode waits 3 secs with 'showmode' enabled or when there are error messages.
Solution:
Remove the delay for "ui2", by using `msg_delay`.
Problem:
TUI does not support several standard SGR text attributes:
- dim/faint (SGR 2)
- blink (SGR 5)
- conceal (SGR 8)
- overline (SGR 53)
This means that when a program running in the embedded terminal emits
one of these escape codes, we drop it and don't surface it to the
outer terminal.
Solution:
- Add support for those attributes.
- Also add corresponding flags to `nvim_set_hl` opts, so users can set
these attributes in highlight groups.
- refactor(highlight): widen `HlAttrFlags` from `int16_t` to `int32_t`
Widen the `rgb_ae_attr` and `cterm_ae_attr` fields in HlAttrs from
int16_t to int32_t to make room for new highlight attribute flags,
since there was only one spare bit left.
- The C flag is named HL_CONCEALED to avoid colliding with the
existing HL_CONCEAL in syntax.h (which is a syntax group flag, not
an SGR attribute).
- Also note that libvterm doesn't currently support the dim and overline
attributes, so e.g. `printf '\e[2mThis should be dim\n'` and `printf
'\e[53mThis should have an overline\n'` are still not rendered
correctly when run from the embedded terminal.
Problem: filetype: sh filetype used for env files
Solution: Detect *.env and .env.* files as env filetype,
detect .envrc and .envrc.* as sh filetype,
include a simple env syntax script (DuckAfire)
Previously, .env files were handled by the shell syntax. While
functional, this limited the ability to support specific .env
implementations, such as CodeIgniter4 which allows dots in keys
(e.g., "foo.bar=0").
The new dedicated 'env' filetype and syntax script improves legibility
and prevents highlighting from breaking when encountering spaces.
Currently, the syntax does not support indentation; fields, variables,
and comments must start at the beginning of the line.
closes: vim/vim#19260d0fa375629
Co-authored-by: DuckAfire <155199080+duckafire@users.noreply.github.com>
The Progress syntax file gained `set expandtab` in 4c3f536f4 (updated
for version 7.0d01, 2006-04-11). The Progress language itself doesn't
distinguish between tabs and spaces for indentation, so this seems like
something that should be left to user preference; but the setting is
accompanied by the comment "The Progress editor doesn't cope with tabs
very well", so there may be reason to keep it.
However, using `set` means that any new buffers created after editing a
Progress file will also have `expandtab` turned on, which is likely
contrary to a user's expectations. We should use `setlocal` instead to
avoid this.
closes: vim/vim#19458342ae5f8aa
Co-authored-by: Daniel Smith <daniel@rdnlsmith.com>