Problem: Profiling functionality is spread out.
Solution: Put profiling functionality in profiling.c. (Yegappan Lakshmanan,
closesvim/vim#4666)
fa55cfc69d
Move proftime_T to types.h for now to avoid recursive #include.
The targets will only format files that have been changed in current
branch compared to the master branch. This includes unstaged, staged and
committed files.
Add following make and cmake targets:
formatc - format changed c files
formatlua - format changed lua files
format - run formatc and formatlua
Remove scripts/uncrustify.sh as this deprecates it.
Most casts where PVS warns for V1028 aren't added to prevent overflows
in the first place, but to avoid other warnings, like printf argument or
-Wconversion warnings. PVS/V1028 is more annoying than useful.
It currently falls back to texlua if luajit doesn't exist. However,
the documentation generation does not work with texlua. Instead use lua
as a fall back instead.
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 })
```
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.
## Overview
- Move vim.lsp.diagnostic to vim.diagnostic
- Refactor client ids to diagnostic namespaces
- Update tests
- Write/update documentation and function signatures
Currently, non-LSP diagnostics in Neovim must hook into the LSP subsystem. This
is what e.g. null-ls and nvim-lint do. This is necessary because none of the
diagnostic API is exposed separately from the LSP subsystem.
This commit addresses this by generalizing the diagnostic subsystem beyond the
scope of LSP. The `vim.lsp.diagnostic` module is now simply a specific
diagnostic producer and primarily maintains the interface between LSP clients
and the broader diagnostic API.
The current diagnostic API uses "client ids" which only makes sense in the
context of LSP. We replace "client ids" with standard API namespaces generated
from `nvim_create_namespace`.
This PR is *mostly* backward compatible (so long as plugins are only using the
publicly documented API): LSP diagnostics will continue to work as usual, as
will pseudo-LSP clients like null-ls and nvim-lint. However, the latter can now
use the new interface, which looks something like this:
```lua
-- The namespace *must* be given a name. Anonymous namespaces will not work with diagnostics
local ns = vim.api.nvim_create_namespace("foo")
-- Generate diagnostics
local diagnostics = generate_diagnostics()
-- Set diagnostics for the current buffer
vim.diagnostic.set(ns, diagnostics, bufnr)
```
Some public facing API utility methods were removed and internalized directly in `vim.diagnostic`:
* `vim.lsp.util.diagnostics_to_items`
## API Design
`vim.diagnostic` contains most of the same API as `vim.lsp.diagnostic` with
`client_id` simply replaced with `namespace`, with some differences:
* Generally speaking, functions that modify or add diagnostics require a namespace as their first argument, e.g.
```lua
vim.diagnostic.set({namespace}, {bufnr}, {diagnostics}[, {opts}])
```
while functions that read or query diagnostics do not (although in many cases one may be supplied optionally):
```lua
vim.diagnostic.get({bufnr}[, {namespace}])
```
* We use our own severity levels to decouple `vim.diagnostic` from LSP. These
are designed similarly to `vim.log.levels` and currently include:
```lua
vim.diagnostic.severity.ERROR
vim.diagnostic.severity.WARN
vim.diagnostic.severity.INFO
vim.diagnostic.severity.HINT
```
In practice, these match the LSP diagnostic severity levels exactly, but we
should treat this as an interface and not assume that they are the same. The
"translation" between the two severity types is handled transparently in
`vim.lsp.diagnostic`.
* The actual "diagnostic" data structure is: (**EDIT:** Updated 2021-09-09):
```lua
{
lnum = <number>,
col = <number>,
end_lnum = <number>,
end_col = <number>,
severity = <vim.diagnostic.severity>,
message = <string>
}
```
This differs from the LSP definition of a diagnostic, so we transform them in
the handler functions in vim.lsp.diagnostic.
## Configuration
The `vim.lsp.with` paradigm still works for configuring how LSP diagnostics are
displayed, but this is a specific use-case for the `publishDiagnostics` handler.
Configuration with `vim.diagnostic` is instead done with the
`vim.diagnostic.config` function:
```lua
vim.diagnostic.config({
virtual_text = true,
signs = false,
underline = true,
update_in_insert = true,
severity_sort = false,
}[, namespace])
```
(or alternatively passed directly to `set()` or `show()`.)
When the `namespace` argument is `nil`, settings are set globally (i.e. for
*all* diagnostic namespaces). This is what user's will typically use for their
local configuration. Diagnostic producers can also set configuration options for
their specific namespace, although this is generally discouraged in order to
respect the user's global settings. All of the values in the table passed to
`vim.diagnostic.config()` are resolved in the same way that they are in
`on_publish_diagnostics`; that is, the value can be a boolean, a table, or
a function:
```lua
vim.diagnostic.config({
virtual_text = function(namespace, bufnr)
-- Only enable virtual text in buffer 3
return bufnr == 3
end,
})
```
## Misc Notes
* `vim.diagnostic` currently depends on `vim.lsp.util` for floating window
previews. I think this is okay for now, although ideally we'd want to decouple
these completely.
This generalizes diagnostic handling outside of just the scope of LSP.
LSP clients are now a specific case of a diagnostic producer, but the
diagnostic subsystem is decoupled from the LSP subsystem (or will be,
eventually).
More discussion at [1].
[1]: https://github.com/neovim/neovim/pull/15585
Adding the version we just released in the "version bump" commit is
useless, since that means the actual release only reports the old
version.
Closes#15362
[skip ci]
The "pull_request" trigger only enables read-access for forks,
"pull_request_target" is required if a fork is to be a trigger. Also
changed the python script to reflect this change.
