Updated inputs so no need to add tree-sitter ourselves anymore.
Added checks:
- for pylint/shlint
- distinguish the devolpment shell from the ASAN build (closure for ASAN
version is smaller). While in the devShell, functionaltests would fail
because bin/nvim could not load
outputs/out/share/nvim/syntax/syntax.vim
So we touch the file.
`flakes` is a feature available in the unstable version of the `nix` package manager
to ease the distribution of nix expressions see https://www.tweag.io/blog/2020-05-25-flakes/ .
Nix excels at software reproducibility and is available/can be
installed on different distributions (ubuntu/void/debian etc) as well
as macOS.
This flakes contains 3 packages that can be installed via for instance
`nix run 'github:neovim/neovim?dir=contrib#nvim-debug'`
or
`nix run 'github:neovim/neovim?dir=contrib'` for the default version.
you can register an alias
`nix registry add neovim 'github:neovim/neovim?dir=contrib'`
and the previous commands become:
`nix run neovim`
Using it takes 30+ additional seconds for me with a ccache-enabled build
(43s vs. 12s).
While it certainly makes sense to use DEBUG during development,
bisecting etc, it should be made clearer what causes this.
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.
The main purpose of this build-type was to avoid unwanted ~/.nvimlog
files (which could get really big, and also affects performance) for
non-devs. But that is no longer necessary since the log system now
avoids non-critical logging by default (#6827).
This essentially reverts 87e5a41316
- Establish ERROR log level as "critical". Such errors are rare and will
be valuable when users encounter unusual circumstances.
- Set -DMIN_LOG_LEVEL=3 for release-type builds
- Remove some unnecessary code: IsHeaderFile is no longer required, as the logic
to find flags to headers is now built into YCM
- Add function to make paths in flags absolute: It seems YCM is not correctly
resolving paths in flags to consider `build` as the compiler working
directory.
- Update documentation.
We use a Makefile which in turn uses cmake. If we wanted to set the install
prefix for cmake, we had to do this so far:
make CMAKE_FLAGS="-DCMAKE_INSTALL_PREFIX=/tmp/nvim"
That's long and hard to remember. Following the conventions of other Makefiles,
this now works as well and is equivalent:
make PREFIX=/tmp/nvim
- Check if MIN_LOG_LEVEL value is a number 0-3, default to
INFO (1) or ignore it in Release mode
- When TRAVIS_CI_BUILD is ON the default is DEBUG (0)
- Add local.mk.example
"vimrc" refers to all files that are used to configure Neovim. The main
configuration file is init.vim nowadays.
All nvimrc references that are left refer to a local ".nvimrc" which is read
if 'exrc' is set. ".ngvimrc" references were completely wiped.
Closes#3552.
Introduce new build type Dev that replaces RelWithDebInfo for development
builds off master and has optimizations, debug info, and logging enabled.
Keep assertions enabled for RelWithDebInfo.
What works:
1. ShaDa file dumping: header, registers, jump list, history, search patterns,
substitute strings, variables.
2. ShaDa file reading: registers, global marks, variables.
Most was not tested.
TODO:
1. Merging.
2. Reading history, local marks, jump and buffer lists.
3. Documentation update.
4. Converting some data from &encoding.
5. Safer variant of dumping viminfo (dump to temporary file then rename).
6. Removing old viminfo code (currently masked with `#if 0` in a ShaDa file for
reference).
This library makes it easier to script communication with interactive programs.
It is similar to what the "expect" tcl extension does, but uses an object
oriented API and is designed to integrate nicely with Neovim job control.
Problem: YCM was reporting a much disturbing warning about a missing
newline at the end of some files. This was odd, as the
newlines were there and the warning only was shown for some
files, not for all of them.
Cause: After discussing this issue with @Valloric (see
https://github.com/Valloric/YouCompleteMe/issues/950), it
turned out that not YCM, but libclang is responsible for it.
This is, same compilation flags that produce no warnings with
clang-the-binary on the command line, do produce them with
libclang-the-library when used by YCM.
Solution: Add an extra flag (-Wno_newline_eof) to those extracted from
configuration database before passing them to YCM.
