The following script is cut out from vim-patch.sh:
```sh
#!/usr/bin/env bash
BASENAME=vim-patch.sh
printf "\nInstructions:
To port one of the above patches to Neovim, execute this script with the patch revision as argument and follow the instructions, e.g.
'%s -p v8.0.1234', or '%s -P v8.0.1234'
NOTE: Please port the _oldest_ patch if you possibly can.
You can use '%s -l path/to/file' to see what patches are missing for a file.
" "${BASENAME}" "${BASENAME}" "${BASENAME}"
```
The code itself should be correct, but shellcheck 0.7.0 says:
```
In /tmp/test.sh line 5:
printf "\nInstructions:
^-- SC2183: This format string has 2 variables, but is passed 3 arguments.
```
We also had a problem before that a `%s` was added, but the accompanying
argument to printf was forgotten. Using a heredoc is less error-prone, since we
insert variables directly.
Judging class definitions in the form "string.find (line, '=% s * class% (')"
must force writing class definitions in this format, but such a mechanism is Absent.
Also, Lua has no formal class in the language specification, and implements inheritance with setmetadable.
To detect this, we should have a parser for it, not a simple regular expression.
Convenient for API clients who want to reuse the API docs in their own
docs. Could be used e.g. to eliminate nvim.net's own doxygen parser:
3a736232a4/src/NvimClient.APIGenerator/Docs
TODO: currently the result values are formatted as Vim help docs. We
should change the values to have structure, something like this:
[{
'nvim_win_get_var': [
'line1,
'line2',
[ 'item1', 'item2', ... ]
],
'nvim_win_set_var': [
...
],
...
}]
close#11296
Avoid noise during builds:
> fatal: No annotated tags can describe '417449f468c4ba186954f6295b3338fb55ee7b4a'.
> However, there were unannotated tags: try --tags.
This might be useful in general, but is expected to not happen - and
falling back is OK then. The fallback command would still display
errors then.
It also uses `--first-parent`, which is important for when a release
branch gets merged back.
* Fix/keep massaging git-describe result
Ref: https://github.com/neovim/neovim/pull/11117#issuecomment-536416223
* build: revisit generation of version from Git
Fixes "make clean && make", where "auto/versiondef.h" would be missing
since b18b84d - because BYPRODUCTS are apparently removed when cleaning.
This includes the following improvements/changes:
- do not run git-describe during CMake's configure phase just for
reporting
- do not print with changed Git version (too noisy, simplifies code)
* Move to src/nvim (included before config) for easier flow
* fallback to describe always, write empty include file
* update_version_stamp.lua: use prefix always
This avoids invoking CMake after a new commit, which might take 15s on
some systems.
Skipped on CMake < 3.2.0 (missing BYPRODUCTS support).
Co-Authored-By: Justin M. Keyes <justinkz@gmail.com>
Replace "src/nvim/" => "src/".
Replace ".*/.vim-src/" => "".
This allows to use tab completion based on existing files in Neovim's
source, or via .vim-src.
Previously you would have to typically remove the "nvim/" part manually
yourself.
Align matchit.vim with upstream Vim. We don't want to maintain a fork of
matchit.vim; our small changes should be sent to
https://github.com/chrisbra/matchit
* scripts/vim-patch.sh: fall back to "origin" for remote
Without this, it would fail e.g. with a locally cloned repo of Neovim.
* scripts/vim-patch.sh: assign_commit_details: handle tags [ci skip]
- Handle "v" prefix from Vim tags.
- Exit in case of error therein already.
* -l/-L: pass through git-log options [ci skip]
This allows for only listing missing patches for a given Vim file:
> scripts/vim-patch.sh -L src/edit.c
`vim-patch.sh -L`: down to ~0.5s from ~85s.
`vim-patch.sh -l`: down to ~6s from ~90s.
% diff old new:
193c193
< • v8.0.1366
---
> • v8.0.1367
354d353
< • v8.0.1738
This is due to duplicate tags for Vim commits
(https://github.com/vim/vim/issues/4510):
- vim/vim@1ad022a9b: tagged as v8.0.1367, v8.0.1366
- vim/vim@5d69da462: tagged as v8.0.1739, v8.0.1738
- render_node() is now the main rendering function: it traverses a node
and builds the Vim help text recursively.
- render_para() is weird and ugly, it is the entry-point for rendering
the help text for one docstring'd function.
- Any long symbol is intentional and should never be hardwrapped.
- Vim help tags are often hyphenated, and hardwrapping on hyphens breaks
the Vim help syntax parser.
Reverts previous experiment. PVS root is working correctly, one can
observe this in the PVS-studio.err file, for example:
/usr/local/clang-7.0.0/lib/clang/7.0.0/include/stddef.h:51:1: warning: V677 ...
/usr/local/clang-7.0.0/lib/clang/7.0.0/include/stddef.h:132:1: warning: V677 ...
./src/nvim/fileio.c:1382:1: warning: V1026 ...
./src/nvim/fileio.c:1388:1: warning: V1026 ...
The "./src/nvim/…" paths are correctly rooted, yet PVS somehow still
thinks it should analyze "/usr/local/clang-7.0.0/…".
See also: https://stackoverflow.com/q/44906903
