Problem: The eval.txt help file is way too big.
Solution: Move the builtin function details to a separate file.
https://github.com/vim/vim/commit/1cae5a0a034d0545360387407a7a409310f1efe2
Note: Neovim-specific references to |functions| were changed to
|builtin-functions|. This included updates to:
1. test/functional/vimscript/functions_spec.lua
2. test/functional/vimscript/eval_spec.lua
3. runtime/doc/lua.txt
These versions of python has reached End-of-life. getting rid
of python2 support removes a lot of logic to support two
incompatible python versions in the same version.
An extra backtick was explicitly written to show what a backtick looked
like, but it interferes with the syntax highlighting which thinks that
it's a part of a concealed group and couples it with the wrong backtick.
When trying to load a language parser, escape the value of
the language.
With language injection, the language might be picked up from the
buffer. If this value is erroneous it can cause `nvim_get_runtime_file`
to hard error.
E.g., the markdown expression `~~~{` will extract '{' as a language and
then try to get the parser using `parser/{*` as the pattern.
This is a follow-on to #17040. The real benefit of #17040 was ensuring
that the ftplugin FileType autocommand was defined first and thus always
fired first. A side effect of the implementation in #17040 was that
setting variables that modified the state of filetype detection (such as
g:did_load_filetypes or g:do_filetype_lua) could no longer be set in the
user's init file. Filetype detection can also no longer be prevented
from loading by using `:filetype off`.
This PR addresses both of those side effects by unconditionally sourcing
ftplugin.vim and indent.vim before the user's init file (which ensures
that these autocommands run first) and sourcing filetype.vim *after* the
user's init file (thus allowing it to be blocked or modified).
When `man -w` is called with an empty string as section name, it may
fail with an error code, which causes :Man to no longer work without a
section. Just remove that argument when no section is specified.
This commits introduces two performance improvements in incremental sync:
* avoiding expensive lua string reallocations on each on_lines call by requesting
only the changed chunk of the buffer as reported by firstline and new_lastline
parameters of on_lines
* re-using already allocated tables for storing the resulting lines to reduce the load on
the garbage collector
The majority of the performance improvement is from requesting only changed chunks
of the buffer.
Benchmark:
The following code measures the time required to perform a buffer edit to
that operates individually on each line, common to plugins such as vim-commentary.
set rtp+=~/.config/nvim/plugged/nvim-lspconfig
set rtp+=~/.config/nvim/plugged/vim-commentary
lua require('lspconfig')['ccls'].setup({})
function! Benchmark(tries) abort
let results_comment = []
let results_undo = []
for i in range(a:tries)
echo printf('run %d', i+1)
let begin = reltime()
normal gggcG
call add(results_comment, reltimefloat(reltime(begin)))
let begin = reltime()
silent! undo
call add(results_undo, reltimefloat(reltime(begin)))
redraw
endfor
let avg_comment = 0.0
let avg_undo = 0.0
for i in range(a:tries)
echomsg printf('run %3d: comment=%fs undo=%fs', i+1, results_comment[i], results_undo[i])
let avg_comment += results_comment[i]
let avg_undo += results_undo[i]
endfor
echomsg printf('average: comment=%fs undo=%fs', avg_comment / a:tries, avg_undo / a:tries)
endfunction
command! -bar Benchmark call Benchmark(10)
All text changes will be recorded within a single undo operation. Both the
comment operation itself and the undo operation will generate an on_lines event
for each changed line. Formatter plugins using setline() have also been found
to exhibit the same problem (neoformat, :RustFmt in rust.vim), as this function
too generates an on_lines event for every line it changes.
Using the neovim codebase as an example (commit 2ecf0a4)
with neovim itself built at 2ecf0a4 with
CMAKE_BUILD_TYPE=Release shows the following performance improvement:
src/nvim/lua/executor.c, 1432 lines:
- baseline, no optimizations: comment=0.540587s undo=0.440249s
- without double-buffering optimization: comment=0.183314s undo=0.060663s
- all optimizations in this commit: comment=0.174850s undo=0.052789s
src/nvim/search.c, 5467 lines:
- baseline, no optimizations: comment=7.420446s undo=7.656624s
- without double-buffering optimization: comment=0.889048s undo=0.486026s
- all optimizations in this commit: comment=0.662899s undo=0.243628s
src/nvim/eval.c, 11355 lines:
- baseline, no optimizations: comment=41.775695s undo=44.583374s
- without double-buffering optimization: comment=3.643933s undo=2.817158s
- all optimizations in this commit: comment=1.510886s undo=0.707928s
Co-authored-by: Dmytro Meleshko <dmytro.meleshko@gmail.com>
This includes a partial port of Vim patch 8.2.2569 and some changes to
nvim_eval_statusline() to allow a multibyte fillchar. Literally every
line of C code touched by that patch has been refactored in Nvim, and
that patch contains some irrelevant foldcolumn tests I'm not sure how to
port (as Nvim's foldcolumn behavior has diverged from Vim's).
zeertzjq