We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
Tests are flaky, and a failure doesn't necessarily impart useful
information. Furthermore, we don't need to link to the tests as it's
just as easy to reach it from the Actions tab.
Having a workflow that only builds neovim without running all of the
tests is a cheap way to test the build still works without burning too
much CI time.
- try to make the CI badge more reliable
- remove "snap" badge, it's too specific and doesn't show stats
- remove twitter link because it's already linked from
https://github.com/neovim and https://neovim.io/ , and it's not super
necessary in the readme.
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/)
helpers.source() was a hack to work around the lack of anonymous
:source. Its "create tempfile" behavior is not a required part of most
tests that use it.
Some tests still need the old "create tempfile" behavior either because
they test SID behavior, or because of missing nvim_exec features: #16071
The entry "To skip bundled (third-parth/*) dependencies:" contains
inappropriate content.
- Lack of description of lua-luv-dev.
- Lack of description of libtree-sitter-dev.
- Contains libutf8proc-dev, which is no longer needed.
- The package libvterm-dev is out of date and probably unusable.
Therefore, it is not possible to build according to this description.
Also, there are only descriptions for Debian and Ubuntu. For these reasons,
this item will be deleted.
The page is useful because it contains:
How to install it
Package information (e.g. current version)
List of dependencies
Analytics (how many people are using it)
There was never any investigation done to determine whether using
jemalloc was actually a net benefit for nvim. It has been a portability
limitation and adds another factor to consider when triaging issues.
dundargoc