This allows the user to detach an active buffer from the language
client. If no clients remain attached to a buffer, the on_lines callback
is used to cancel nvim_buf_attach.
Previously, the `_str_utfindex_enc` and `_str_byteindex_enc` helper functions would return `nil` when `offset_encoding == "utf-8"` and `index == nil`. Clearly, this doesn't reflect the expected behavior of the functions they're wrapping which would return the length of the line in this case. This should fix behavior with servers that use UTF-8 `offset_encoding` when applying text edits, formatting a range, and doing range code actions (though this isn't tested currently).
Include a build option to explicitly disable Lua bytecode compilation.
This is needed in some situations where the existing checks are not
sufficient (e.g. cross compilation).
Closes https://github.com/neovim/neovim/issues/16562https://github.com/neovim/neovim/issues/16249https://github.com/neovim/neovim/issues/16297
* buf_attach_client can be called on an unloaded buffer
* on_attach will prematurely fail, while the language server client
tracks this buffer as attached
* The language server client will track this buffer as attached despite
textDocument/didChange notifications not being sent to the server
* Instead, check if the buffer is loaded and return early, warning via
the lsp logger that buf_attach_client was called on an invalid buffer
Apparently some installations of LuaJIT do not have the "jit.bcsave"
module which is required for pre-compilation. Check that this module
exists before using LuaJIT as luac and if it doesn't, skip compiling
bytecode.
If the LUAC_PRG environment variable is defined, but empty, compilation
would still be attempted but would be malformed. This results in garbage
bytes being included.
Fix this by checking that LUAC_PRG is both defined *and* non-empty.
Problem: Dep3patch files are not recognized.
Solution: Recognize dep3patch files by their location and content. (James
McCoy, closesvim/vim#9367)
647ab4cede
docs(reg_recorded): add links to relevant docs
docs(Recording): update docs to match implementation
docs(Q) update references of Q to be gQ
docs(autocmd) add description about state of reg_record{ing,ed} for RecordingLeave
docs(vim_diff) add Recording{Enter,Leave} to features
docs(index) removed duplicate gQ
docs(options) removed line about gQ erroring in visual mode
Update runtime/doc/vim_diff.txt
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
docs(vim_diff) removed double mention of Q
feat(eval): add reg_recorded()
This function is used the get the last recorded register.
style(Recording): rename handler to match suggestions
fix(RecordingLeave): send autocommand earlier
This makes the autocommand fire just before setting reg_recorded to
reg_recording, this way we clearly show that we are actually just before
actually quitting the recording mode.
The `prefix_source` function only evaluates the sources from the
diagnostics passed to it; however, because each namespace draws its own
virtual text, its diagnostics will never contain more than a single
source (by definition). This requires changing the semantics of what
"if_many" means from "multiple sources in a single 'batch' of
diagnostics" to "multiple sources of all diagnostics within a buffer".
Closes#16624
Fixes two issues with aligning the start position and end position to
codepoints when calculating the start and end range.
When aligning the start position:
* use aligned byte index to calculate character index rather than
the unadjusted byte
When aligning the end position:
* do not adjust the end byte if it falls on a UTF-8 codepoint
* align byte to the first byte of the next codepoint rather than the
last byte of the current codepoint
* compute character character end range on the aligned byte index
This commit also adds additional test coverage, including multibyte operations
that previously failed before this commit.
The on_exit handler provided to the client configuration is called after
the client's context is cleared (e.g. which buffers the client was
attached to). Calling the handler sooner allows these handlers to access
the client object and do their own cleanup with the full context.
Line number and column are required and much of the diagnostic API
assumes that these are both present. When one of the two is missing,
cryptic errors pop up in other parts of the diagnostic subsystem.
Instead, assert that diagnostics are well formed when they are entered
into the cache, which provides a clearer error.
The Lua modules that make up vim.lua are embedded as raw source files into the
nvim binary. These sources are loaded by the Lua runtime on startuptime. We can
pre-compile these sources into Lua bytecode before embedding them into the
binary, which minimizes the size of the binary and improves startuptime.
* str_utf_start/end both cast the offset into the utf string
to a char_u, a pointer + long is well-defined and the cast is
unnecessary. This previously resulted in issues for offsets greater than
256.
refresh_scrollback assumes pending scrollback rows exist only if the
terminal window height decreased (or the screen was full).
However, after accumulating scrollback, it's possible in some cases for
the terminal height to increase before refresh_scrollback is called via
invalidation (especially when the terminal buffer isn't initially
displayed in a window before nvim_open_term), which may crash.
As we'll have enough room for some scrollback rows, just append them to
the top of the buffer until it fills the window, then continue with the
previous logic for any remaining scrollback rows if necessary.
When buffer is visible in two splits simultaneously, BufHidden event is
not triggered, causing the floating window to remain on screen after
switching to another buffer.
Remove BufHidden event from close_events defaults, and close the window
if we changed the buffer to something other than the buffer that spawned
the floating window or the floating window buffer itself.
When filling a quickfix/loclist from a string-typed VimL variable, the
complexity is O(N^2) in the number of lines in the variable.
The problem is caused by using `xstrlcpy(3)` to copy the characters from
the current position up to the next newline into the quickfix/loclist
buffer in a loop.
strlcpy(3) returns the length of `src`, so by necessity it has to
compute `strlen(src)`. This means scanning the full rest of the typval
on every iteration while only copying a small fraction (up to the next
'\n').
This is not a problem whenever the srclen-to-copylen ratio is close to
1, which it usually is. But not in this case. Since we already
calculated exactly how many bytes we want to copy, we should be using
memcpy(3).
This problem is not present in Vim, as it uses `vim_strncpy`, a
`strncpy(3)`-alike, which stops at either `\0` or `n`, whichever comes
first.
The quickfix/loclist window can be filled using a:
1. File (used by commands like :grep/:make/... to source directly
from their errorfile)
2. Buffer (used by :cbuffer and its variants)
3. Typval
a. String (used by :cexpr and its variants)
b. List of strings (used by setqflist(), setloclist(), :cepxr and its
variants)
This commit optimizes case (3a), especially when the typval is a long
string.
The pathological path is triggered by (e.g.) :grep enhancements as found
in https://gist.github.com/romainl/56f0c28ef953ffc157f36cc495947ab3:
function! Grep(...)
return system(join([&grepprg] + a:000), ' '))
endfunction
:cgetexpr Grep('foo')
It would've been better for Neovim to use `systemlist` here, before this
commit.
