Getting current channel info was kind of annoying via RPC. Two
functions had to be called:
1. `nvim_get_api_info` which returns `[channel_id, meta_data]`.
- This results in `channel_id = api.nvim_get_api_info()[0]`.
- Here the meta_data is sent but never used.
2. Finally call `nvim_get_chan_info(channel_id)`.
This commit reduces the need for `nvim_get_api_info` as passing 0
returns current channel info.
runtime(doc): Clarify list-concatenation a bit more
Make doc list-concatenation more clear as for += and extend().
1. describe `+=` for list-concatenation more accurately
2. add `extend()` example for list-concatenation
3. Fix CI errors for missing helptags reference |+=|
closes: vim/vim#13983c9c2e2d2ff
Co-authored-by: qeatzy <qeatzy@users.noreply.github.com>
Problem: unexpected error for modifying final list using += operator
(Ernie Rael)
Solution: Allow List value modification of a final variable using +=
operator
(Yegappan Lakshmanan)
fixes: vim/vim#13745fixes: vim/vim#13959closes: vim/vim#139621af35631f8
Only port eval.txt changes.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem:
The LSP client code is implemented as a complicated closure-class
(class defined in a single function).
Solution:
Move LSP client code to a more conventional Lua class and move to a
separate file.
runtime(dosbatch): improve '::' comment highlighting
Added a syntax region for command blocks so that the highlighting of
`::` comments in them can be controlled. The `dosbatch_colons_comment`
variable now controls if all `::` comments in a code block are
highlighted as comments or errors. A `::` comment at the end of a
command block is always highlighted as an error.
This re-enables the highlighting of `::` comments in `.bat` files as
requested in vim/vim#13666, while allowing control of highlighting them in
command blocks requested in vim/vim#11778 and first attempted in vim/vim#11980.
related: vim/vim#11980fixes: vim/vim#13666f7f33e3719
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Mike Williams <mikew@globalgraphics.com>
Problem:
- `:InspectTree` was showing node ranges in 1-based indexing, i.e., in
vim cursor position (lnum, col). However, treesitter API adopts
0-based indexing to represent ranges (Range4). This can often be
confusing for developers and plugin authors when debugging code
written with treesiter APIs.
Solution:
- Change to 0-based indexing from 1-based indexing to show node ranges
in `:InspectTree`.
- Note: To make things not complicated, we do not provide an option or
keymap to configure which indexing mode to use.
runtime(vim): Update syntax file (vim/vim#13969)
Improve string interpolation highlighting.
Use the vimSep group to highlight interpolation braces as vimOperParen
has no highlighting of its own and employs vimSep via matchgroup.
Add vimNumber to the interpolation group's contained list.
7c5aeaffa2
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: vim.lsp.tagfunc() causes an infinite loop.
This is a bug happened while introducing deferred loading.
Solution: Rename the private module to `vim.lsp._tagfunc`.
The benefit of this is that users only pay for what they use. If e.g.
only `vim.lsp.buf_get_clients()` is called then they don't need to load
all modules under `vim.lsp` which could lead to significant startuptime
saving.
Also `vim.lsp.module` is a bit nicer to user compared to
`require("vim.lsp.module")`.
This isn't used for some nested modules such as `filetype` as it breaks
tests with error messages such as "attempt to index field 'detect'".
It's not entirely certain the reason for this, but it is likely it is
due to filetype being precompiled which would imply deferred loading
isn't needed for performance reasons.
Problem:
Processing non-fast events during SystemObj:wait() may cause two pieces
of code to interfere with each other, and is different from jobwait().
Solution:
Don't process non-fast events during SystemObj:wait().
runtime(vim): Improve keymap file highlighting (vim/vim#13550)
- Match :loadkeymap to EOF as a region and contain only allowed items.
- Add highlighting for <Char- notation.
- add basic syntax highlighting tests
69866449dd
N/A patches:
vim-patch:35928ee8f80ea721e92bb856c8ecde2cced46bb9
vim-patch:b5352931b354eb67eb7d223cc09c98dcf1b547b6
Co-authored-by: dkearns <dougkearns@gmail.com>
- Consistently use the variable CMAKE_BUILD_TYPE to select build type.
- Remove broken `doc_html` target.
- Remove swap files created by oldtest when cleaning.
- Only rerun `lintdoc` if any documentation files has changed.
runtime(netrw): fixing remote file removal via ssh (vim/vim#13942)
Make pattern, which retrieves the path component from e.g.
`scp://user@host//opt/program/file.ext` non-greedy.
c46c21b4ca
Co-authored-by: MiguelBarro <45819833+MiguelBarro@users.noreply.github.com>
runtime(racket): add missing space to b:undo_indent var (vim/vim#13945)
This copies commit 2a4862a (fixup! indent: only reset some options when
has vim9, 2024-01-31) from https://github.com/benknoble/vim-racket and
fixes 26b0176a9 (runtime(racket): undo some indent options only when
vim9script is available (vim/vim#13935), 2024-01-30).
83f627ff42
Co-authored-by: D. Ben Knoble <ben.knoble+github@gmail.com>
runtime(racket): undo some indent options only when vim9script is available (vim/vim#13935)
This copies commit 64edf95 (indent: only reset some options when has
vim9, 2024-01-30) from https://github.com/benknoble/vim-racket.
26b0176a98
Co-authored-by: D. Ben Knoble <ben.knoble+github@gmail.com>
Problem: UX of visual highlighting can be improved
Solution: Improve readibility of visual highlighting,
by setting better foreground and background
colors
The default visual highlighting currently is nice in that it overlays
the actual syntax highlighting by using a separate distinct background
color.
However, this can cause hard to read text, because the contrast
between the actual syntax element and the background color is way too
low. That is an issue, that has been bothering colorschemes authors for
quite some time so much, that they are defining the Visual highlighting
group to use a separate foreground and background color, so that the
syntax highlighting vanishes, but the text remains readable (ref:
vim/colorschemesvim/vim#250)
So this is an attempt to perform the same fix for the default Visual
highlighting and just use a default foreground and background color
instead of using reverse.
I also removed the hard-coded changes to the Visual highlighting in
init_highlight. It's not quite clear to me, why those were there and not
added directly to the highlighting_init_<dark|light> struct.
closes: vim/vim#13663
related: vim/colorschemes#250e6d8b4662d
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(vim): Update syntax and ftplugin files (vim/vim#13924)
Improve matching of line-continuations and interspersed comments.
These are now also matched in multiline syntax command patterns,
dictionary literals, and parenthesised expressions and argument lists.
21ce159e05
Co-authored-by: dkearns <dougkearns@gmail.com>
The "priority" field of extmarks can be used to set priorities of
extmarks which dictates which highlight group a range will actually have
when there are multiple extmarks applied. However, when multiple
extmarks have the same priority, the only way to enforce an actual
priority is through the order in which the extmarks are set.
It is not always possible or desirable to set extmarks in a specific
order, however, so we add a new "subpriority" field that explicitly
enforces the ordering of extmarks that have the same priority.
For now this will be used only to enforce priority of treesitter
highlights. A single node in a treesitter tree may match multiple
captures, in which case that node will have multiple extmarks set. The
order in which captures are returned from the treesitter API is not
_necessarily_ in the same order they are defined in a query file, so we
use the new subpriority field to force that ordering.
For now subpriorites are not documented and are not meant to be used by
external code, and it only applies to ephemeral extmarks. We indicate
the "private" nature of subpriorities by prefixing the field name with
an "_".
Problem:
If `neovim` module is not installed, python and ruby healthchecks fail:
- ERROR Failed to run healthcheck for "provider.python" plugin. Exception:
.../runtime/lua/provider/python/health.lua:348: attempt to concatenate local 'pyname' (a nil value)
- ERROR Failed to run healthcheck for "provider.ruby" plugin. Exception:
.../runtime/lua/provider/ruby/health.lua:25: attempt to index local 'host' (a nil value)
Solution:
Check for non-nil.
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.
1fb4103206
runtime(ant): Update syntax file (vim/vim#13926)
Remove invalid display option from syn-keyword commands.
Take over maintenance of this file.
0cc6108fea
Co-authored-by: dkearns <dougkearns@gmail.com>
runtime(mail): fixvim/vim#13913 (vim/vim#13917)
switch to the DFA engine for the emoji collaction range
046a0f75d0
Co-authored-by: gi1242 <gi1242+github@gmail.com>
Co-authored-by: GI <gi1242+vim@gmail.com>
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#1269892e90a1e10
Co-authored-by: Casey Tucker <dctucker@hotmail.com>
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.).
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.
runtime(netrw): Don't change global options (vim/vim#13910)
Originally reported at: https://github.com/vim-jp/issues/issues/1428
'isk' was unintentionally changed by netrw, regression
introduced in Commit: 71badf9547e8f89571b9a095183671cbb333d528
a262d3f41b
Co-authored-by: K.Takata <kentkt@csc.jp>
- 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.
runtime(vim): Update syntax file (vim/vim#13906)
Highlight :2match and :3match and add these to :help ex-cmd-index.
9c5b90db03
Co-authored-by: dkearns <dougkearns@gmail.com>
Docs for treesitter would benefit from including more real-world and
practical examples of queries and usages, rather than hypothetical ones
(e.g. names such as "foo", "bar"). Improved examples should be more
user-friendly and clear to understand.
In addition, align the capture names in some examples with the actual
ones being used in the built-in query files or in the nvim-treesitter
plugin, e.g.:
- `@parameter` -> `@variable.parameter`
- `@comment.doc.java` -> `@comment.documentation.java`
- etc.
runtime(doc): change "VIsual mode" to "Visual mode" in :h SafeState (vim/vim#13901)
"Visual mode" is used everywhere else in the help when not referring to
something in the source code.
e13b665a6e
Problem: vim.diagnostic.{underline,float,virtual_text...}.severity
will have a type warning on list-like or table (min-max) inputs,
e.g. `vim.diagnostic.config { float = { severity = { min = INFO } } }`.
Solution: Correct the typing as documented in |diagnostic-severity|.
runtime(sh): Add handling for ksh93 shared-state comsubs and mksh valsubs (vim/vim#13884)
This commit adds support for ksh93 shared-state command
substitutions (syntax: ${ command; }) and mksh's value
substitutions (syntax: ${|command;}) in the sh syntax script.
Also add a syntax test for ksh subshares with dumps included
to make sure it doesn't regress.
fixes: vim/vim#9514add31baeda
Co-authored-by: Johnothan King <johnothanking@protonmail.com>
runtime(chuck): include ChucK syntax file (vim/vim#13895)
3b2c27415d
Co-authored-by: Andrea C from The App <3269984+gacallea@users.noreply.github.com>
Co-authored-by: gacallea <gacallea@users.noreply.github.com>
runtime(go): update Go syntax file (vim/vim#13896)
Update the Go syntax file with some recent changes made to vim-go.
ea9a93e5b0
Co-authored-by: Billie Cleek <bhcleek@users.noreply.github.com>
'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>
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()
When computing on-screen size or position, the size 'breakindent' and 'showbreak' is now cached,
and checks for whether a faster character size function can be used are performed only once at the start.
Multibyte characters are not decodes multiple times anymore, and character decoding functions are more efficient.
Additionally, the amount of trailing spaces for pasted blockwise text is now calculated correctly for multibyte characters.
Internal lisp formatting now doesn't erroneously use inline virtual text from a different line.
- Problem: One cannot easily write something like, for example:
`version_current >= {0, 10, 0}`; writing like
`not vim.version.lt(version_current, {0, 10, 0})` is verbose.
- Solution: add {`le`,`ge`} in addition to {`lt`,`gt`}.
- Also improve typing on the operator methods: allow `string` as well.
- Update the example in `vim.version.range()` docs: `ge` in place of
`gt` better matches the semantics of `range:has`.
Problem: Sharing queries with upstream and Helix is difficult due to
different capture names.
Solution: Define and document a new set of standard captures that
matches tree-sitter "standard captures" (where defined) and is closer to
Helix' Atom-style nested groups.
This is a breaking change for colorschemes that defined highlights based
on the old captures. On the other hand, the default colorscheme now
defines links for all standard captures (not just those used in bundled
queries), improving the out-of-the-box experience.
This distinction is important for correct dependency management, as the
nvim binary is used to create some runtime files. The nvim binary (and
the target to build it) is thus called `nvim_bin` and the target to
build all of nvim (binary+runtime) is called `nvim`.
When an embedded Nvim instance changes its current directory a "chdir"
UI event is emitted. Attached UIs can use this information however they
wish. In the TUI it is used to synchronize the cwd of the TUI process
with the cwd of the embedded Nvim process.
Problem:
On devel(nightly) versions, deprecation warnings for hard-deprecated
features are not being displayed. E.g.,
- to be removed in: 0.11
- hard-deprecation since 0.10
- soft-deprecation since 0.9
then 0.10-nightly (0.10.0-dev) versions as well as 0.10.0 (stable)
should display the deprecation warning message.
Solution:
Improve the code and logic on `vim.deprecate()`, and improve
test cases with mocked `vim.version()`.
Problem: Parsed language annotations can be random garbage so
`nvim_get_runtime_file` throws an error.
Solution: Validate that `alias` is a valid language name before trying
to find a parser for it.
