Most code in keymap.h is for keycode definitions, while most code in
keymap.c is for the parsing and conversion of keycodes.
The name "keymap" may also make people think these two files are for
mappings, while in fact keycodes are used even when no mappings are
involved, so "keycodes" should be a better file name than "keymap".
It's special cased by the vimSubst syntax group, and isn't present in Vim's
vimCommand group.
For example, this fixes `call s:Foo()` highlighting `:` as Error in Nvim, as the
`s` is parsed as vimCommand rather than as vimUserFunc since
`contains=vimCommand` was added to vimUserFunc (and vimFunc) in a rt update.
Interestingly, `g:`, `l:`, etc. have the same issues due to :global, :list, etc.
Vim also has that problem, so it should ideally be fixed upstream.
We could also omit g[lobal] from vimCommand and rely on vimGlobal instead, but
it doesn't work in some cases, like when there's a `:` before the command. Also,
Vim matches only `g` in vimCommand for some reason, which doesn't produce any
highlight for `:global/foo/bar` (with Nvim you at least get some highlights on
the `global` bit despite the leading `:`).
Also, remove special handling of :py3 in syntax/vim.vim, as the generator seems
to have no problems finding it.
When checking the version of the doxygen installed from conda the output
has the following format:
1.9.2 (ee54ebd4f0ad83d9c44f19a459146de64d0ffba2*)
This would cause an error in the "Missing API docs" CI job. This fix
will correctly parse the doxygen version for both stable releases
("1.9.2") as well as the version with the git commit hash attached.
There have been a few instances where developers got confused as to why
their generated documentation differs from the one generated by the CI.
More often than not, the reason is that their doxygen version is older
than 1.9.0, which is the current minimum version. Having a simple
version check will help save future developers avoid this problem.
* fix(PVS/V002): disable rule completely
V002: "Some diagnostic messages may contain incorrect line number in
this file." This particular check seems unreliable. It says on their
website https://pvs-studio.com/en/docs/warnings/v002/ that this warning
occurs when there are multiline pragmas, but there are none in
extmark.c.
* fix(PVS/V756): ignore "counter is not used inside a nested loop" warning
The nested loop starts with "AutoCmd *ac = ap->cmds" so "ap" is
definitely used.
* fix(PVS/V560): disable "a part of conditional expression is always true"
* fix(PVS/V614): potentially uninitialized variable 'blen' used
Problem: Syntax coloring and highlighting is in one big file.
Solution: Move the highlighting to a separate file. (Yegappan Lakshmanan,
closesvim/vim#4674)
f9cc9f209e
Name the new file highlight_group.c instead.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Previously, `delete_lines_below` would raise `FileNotFoundError` when
adding a new file to `CONFIG` and you had to manually write a file with
help tag of the first section as placeholder. This change relieves you
of that need.
Using a here string can cause an error if there are no missing patches:
`./scripts/vim-patch.sh: line 580: runtime_commits: bad array subscript`
Using piping doesn't cause the error.
This introduces two new functions `vim.keymap.set` & `vim.keymap.del`
differences compared to regular set_keymap:
- remap is used as opposite of noremap. By default it's true for <Plug> keymaps and false for others.
- rhs can be lua function.
- mode can be a list of modes.
- replace_keycodes option for lua function expr maps. (Default: true)
- handles buffer specific keymaps
Examples:
```lua
vim.keymap.set('n', 'asdf', function() print("real lua function") end)
vim.keymap.set({'n', 'v'}, '<leader>lr', vim.lsp.buf.references, {buffer=true})
vim.keymap.set('n', '<leader>w', "<cmd>w<cr>", {silent = true, buffer = 5 })
vim.keymap.set('i', '<Tab>', function()
return vim.fn.pumvisible() == 1 and "<C-n>" or "<Tab>"
end, {expr = true})
vim.keymap.set('n', '[%', '<Plug>(MatchitNormalMultiBackward)')
vim.keymap.del('n', 'asdf')
vim.keymap.del({'n', 'i', 'v'}, '<leader>w', {buffer = 5 })
```
Problem:
Because of -u NORC, vim-patch.sh would hang on my machine due to one of my
plugins (start package) waiting for prompt input.
Solution:
- Use -u NONE instead to disable all plugins.
- Also use -n to disable swapfiles. These changes only apply to the --headless
nvim instances used to process things.
The spacing fix drew attention to a couple of places that were using
incorrect formatting such as the key listing for `nvim_open_win`, so
those were fixed too.
Continuation of https://github.com/neovim/neovim/pull/15202
A plugin like telescope could override it with a fancy implementation
and then users would get the telescope-ui within each plugin that
utilizes the vim.ui.select function.
There are some plugins which override the `textDocument/codeAction`
handler solely to provide a different UI. With custom client commands and
soon codeAction resolve support, it becomes more difficult to implement
the handler right - so having a dedicated way to override the picking
function will be useful.
PVS is worried about typos. Now we need it to stop worrying...
Disable these checks entirely, they are all false positives.
tui.c:1873 V1074 Boundary between escape sequence and string is unclear. The escape sequence ends with a letter and the next character is also a letter. Check for typos.
tui.c:1983 V1074 Boundary between escape sequence and string is unclear. The escape sequence ends with a letter and the next character is also a letter. Check for typos.
regexp_nfa.c:6189 V1051 Consider checking for misprints. It's possible that the 'pim->result' should be checked here.
screen.c:2928 V1051 Consider checking for misprints. It's possible that the 'vcol_sbr' should be checked here.
screen.c:3187 V1051 Consider checking for misprints. It's possible that the 'line_attr' should be checked here.
screen.c:3267 V1051 Consider checking for misprints. It's possible that the 'multi_attr' should be checked here.
screen.c:4747 V1051 Consider checking for misprints. It's possible that the 'redraw_next' should be checked here.
syntax.c:3448 V1051 Consider checking for misprints. It's possible that the 'arg_end' should be checked here.
syntax.c:3625 V1051 Consider checking for misprints. It's possible that the 'arg_end' should be checked here.
tui.c:1836 V1051 Consider checking for misprints. It's possible that the 'data->unibi_ext.set_cursor_style' should be checked here.
tui.c:1863 V1051 Consider checking for misprints. It's possible that the 'data->unibi_ext.set_cursor_style' should be checked here.
tui.c:1882 V1051 Consider checking for misprints. It's possible that the 'data->unibi_ext.set_cursor_style' should be checked here.
