Problem: Elapsed time since testing started is not visible.
Solution: Show the elapsed time while running tests.
b9093d5009
Co-authored-by: Bram Moolenaar <Bram@vim.org>
This allows a more declarative way of defining targets which may be easier to those not familiar with cmake quirks.
Example usage:
# get a list of pre-configured presets
cmake --list-presets
# configure a preset
cmake . --preset=default
# build it
cmake --build --preset=default
The Sumneko Lua language server has matured quite a bit and many
Neovim developers use it while working on Neovim. Having a default
configuration for Neovim development is a nice convenience (and
dovetails well with the auto-generated compile_command.json for C
development).
The file is shipped under `contrib` and users can make use of it by
symlinking to `.luarc.json` in the project root.
I build Vim and Nvim from source and have both repos cloned locally. To prevent
vim-patch.sh from downloading the Vim source once again to /.vim-src/, I usually
use a symlink pointing to the already existing Vim repo.
The pattern "/.vim-src" works for both, a directory or a symlink.
- remove redundant autocmd list
This "grouped" list is useless, it only gets in the way when searching
for event names.
- intro.txt: cleanup
- starting.txt: update, revisit
- doc: `:help bisect`
- mbyte.txt: update aliases 1656367b90. closes#11960
- options: remove 'guifontset'. Why:
- It is complicated and is used by almost no one.
- It is unlikely to be implemented by Nvim GUIs (complicated to parse,
specific to Xorg...).
* Fix some small doc issues
* doc: fixup
* doc: fixup
* Fix lint and rebase
* Remove bad advice
* Ugh, stupid mpack files...
* Don't let people include these for now until they specifically want to
* Prevent duplicate tag
Problem: "make test" for indent files doesn't cause make to fail.
Solution: Exit the script with ":cquit". (Daniel Hahler, closesvim/vim#4949)
cd67059c0c
closes#9136
- Treat empty {rhs} like <Nop>
- getchar.c: Pull "repl. MapArg termcodes" into func
The "preprocessing code" surrounding the replace_termcodes calls needs
to invoke replace_termcodes, and also check if RHS is equal to "<Nop>".
To reduce code duplication, factor this out into a helper function.
Also add an rhs_is_noop flag to MapArguments; buf_do_map_explicit
expects an empty {rhs} string for "<Nop>", but also needs to distinguish
that from something like ":map lhs<cr>" where no {rhs} was provided.
- getchar.c: Use allocated buffer for rhs in MapArgs
Since the MAXMAPLEN limit does not apply to the RHS of a mapping (or
else an RHS that calls a really long autoload function from a plugin
would be incorrectly rejected as being too long), use an allocated
buffer for RHS rather than a static buffer of length MAXMAPLEN + 1.
- Mappings LHS and RHS can contain literal space characters, newlines, etc.
- getchar.c: replace_termcodes in str_to_mapargs
It makes sense to do this; str_to_mapargs is, intuitively, supposed to
take a "raw" command string and parse it into a totally "do_map-ready"
struct.
- api/vim.c: Update lhs, rhs len after replace_termcodes
Fixes a bug in which replace_termcodes changes the length of lhs or rhs,
but the later search through the mappings/abbreviations hashtables
still uses the old length value. This would cause the search to fail
erroneously and throw 'E31: No such mapping' errors or 'E24: No such
abbreviation' errors.
- getchar: Create new map_arguments struct
So that a string of map arguments can be parsed into a more useful, more
portable data structure.
- getchar.c: Add buf_do_map function
Exactly the same as the old do_map, but replace the hardcoded references
to the global `buf_T* curbuf` with a function parameter so that we can
invoke it from nvim_buf_set_keymap.
- Remove gettext calls in do_map error handling
vimrc_example.vim is not relevant to Nvim. Anything worth having in
there should be made an actual default.
.gitignore:
- remove *.orig ... super annoying
Vim creates these scripts in test1 depending on what build features
are enabled so that tests that use these features are skiped if
necessary. Because Neovim only has one type of build (and the features
+eval, +windows, and +multi-byte are enabled in this build) they are
not necessary.
Lewis Russell