Problem: The eval.c file is too big.
Solution: Move code related to variables to evalvars.c. (Yegappan
Lakshmanan, closesvim/vim#4868)
0522ba0359
Name the new file eval/vars.c instead.
In case nvim A sends nvim_error_event to nvim B, it would
respond with another nvim_error_event due to unknown
request name. Fix this by adding dummy request handler for now.
- only update git-version if both of these conditions are met:
- `git` command succeeds
- `versiondef_git.h` would change (SHA1-diff)
- else print a status/warning message
also move version generation out of Lua into cmake.
Problem:
Dirs "config", "packaging", and "third-party" are all closely related
but this is not obvious from the layout. This adds friction for new
contributors.
Solution:
- rename config/ to cmake.config/
- rename test/config/ to test/cmakeconfig/ because it is used in Lua
tests: require('test.cmakeconfig.paths').
- rename packaging/ to cmake.packaging/
- rename third-party/ to cmake.deps/ (parallel with .deps/)
This marks the following Vim patches as ported:
vim-patch:8.1.1785: map functionality mixed with character input
Problem: Map functionality mixed with character input.
Solution: Move the map functionality to a separate file. (Yegappan
Lakshmanan, closesvim/vim#4740) Graduate the +localmap feature.
b66bab381c
vim-patch:8.2.3643: header for source file is outdated
Problem: Header for source file is outdated.
Solution: Make the header more accurate. (closesvim/vim#9186)
a3f83feb63
Also cherry-pick a change for <unique> mappings from patch 8.2.0807.
Rename map_clear_mode() to do_mapclear().
In scripts/vim-patch.sh line 335:
printf '
^-- SC2183 (warning): This format string has 4 variables, but is passed 3 arguments.
In scripts/vim-patch.sh line 597:
list_missing_vimpatches 1 "$@" | while read -r vim_commit; do
^--------^ SC2030 (info): Modification of vim_commit is local (to subshell caused by pipeline)
In scripts/vim-patch.sh line 626:
done < <(git -C "${VIM_SOURCE_DIR}" diff-tree --no-commit-id --name-only -r "${vim_commit}" -- . ':!src/version.c')
^-----------^ SC2031 (info): vim_commit was modified in a subshell. That change might be lost.
For more information:
https://www.shellcheck.net/wiki/SC2183 -- This format string has 4 variable...
https://www.shellcheck.net/wiki/SC2030 -- Modification of vim_commit is loc...
https://www.shellcheck.net/wiki/SC2031 -- vim_commit was modified in a subs...
Removes NOLINT, which is pointless for the generated terminfo_defs.h.
Adds `uncrustify:off`, so it is not uncrustify which complains about the same
things (too long lines, no space after comma) instead.
This will check if the string after the variable in a @param is either
"number", "string", "table", "boolean" and "function" and if so add a
parenthesis around it. This will help separate the variable type with
the following text. Had all our functions been annotated with emmylua
then a more robust solution might have been preferable (such as always
assuming the third string is parameter type without making any checks).
I believe however this is a clear improvement over the current situation
and will suffice for now.
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 })
```
