* revert to filetype.vim by setting `g:do_legacy_filetype`
* skip either filetype.lua or filetype.vim via `g:did_load_filetypes`
(Running both is no longer required and therefore no longer supported.)
Problem: Get ml_get error when deleting a line in 'completefunc'. (Yegappan
Lakshmanan)
Solution: Lock the text while evaluating 'completefunc'.
ff06f283e3
Fix a mistake in the porting of patch 8.1.0098.
Cherry-pick Test_run_excmd_with_text_locked() from patch 8.2.0270.
Cherry-pick test_gf.vim changes from patch 8.2.0369.
Cherry-pick message change from later patches.
Add 'mousescroll' option to control how many lines to scroll by when a
mouse wheel keycode is received. The mousescroll option controls both
horizontal and vertical scrolling. The option is a string in the format:
set mousescroll=direction:count,direction:count
Where direction is either "ver" or "hor", and count is a non negative
integer. If a direction is omitted, a default value is used. The default
values remain unchanged, that is 3 for vertical scrolling, and 6 for
horizontal scrolling. As such, the mousescroll default is "ver:3,hor:6".
Add mousescroll documentation
- Add option documentation in options.txt
- Add brief summary in quickref.txt
Update :help scroll-mouse-wheel
- Mention mousescroll option as a means of controlling scrolling.
- Remove obsolete suggestion to map scroll wheel keys to <C-U> to
scroll by a single line -- users should prefer the mousescroll option.
- Add some information about the consequences of remapping scroll wheel
keys (they lose their magic ability to affect inactive windows).
Update :help vim-differences
- Add brief mousescroll summary under Options
Add mousescroll tests
- Test option validation
- Test default mousescroll value and behavior
- Test fallback to default values
- Test mouse vertical and horizontal scrolling in normal mode
- Test mouse vertical and horizontal scrolling in insert mode
Problem: The terminal debugger can't set a breakpoint with the mouse.
Solution: Add popup menu entries.
71137fed4d
This ports missing popup menu code to termdebug plugin.
Despite the commit message, the code is copied from latest Vim.
WinBar code is commented out and WinBar docs is not ported.
vim-patch:9.0.0031: <mods> of user command does not have correct verbose value
Problem: <mods> of user command does not have correct verbose value.
Solution: Use the value from the command modifier. (closesvim/vim#10651)
9359e8a6d9
Problem: Internal error when using :popup.
Solution: When a menu only exists in Terminal mode give an error. (Naruhiko
Nishino, closesvim/vim#3765)
f42b45d719
Problem: No menus specifically for the terminal window.
Solution: Add :tlmenu. (Yee Cheng Chin, closesvim/vim#3439) Add a menu test.
4c5d815256
ADDR_OHTER comes from patch 8.1.1241, which has already been ported.
Problem: Can't use :popup for a menu in the terminal. (Wei Zhang)
Solution: Make :popup work in the terminal. Also fix that entries were
included that don't work in the current state.
29a2c08d79
** Refactor
Previously most functions used to "get" a mark returned a position,
changed the line number and sometimes changed even the current buffer.
Now functions return a {x}fmark_T making calling context aware whether
the mark is in another buffer without arcane casting. A new function is
provided for switching to the mark buffer and returning a flag style
Enum to convey what happen in the movement. If the cursor changed, line,
columns, if it changed buffer, etc.
The function to get named mark was split into multiple functions.
- mark_get() -> fmark_T
- mark_get_global() -> xfmark_T
- mark_get_local() -> fmark_T
- mark_get_motion() -> fmark_T
- mark_get_visual() -> fmark_T
Functions that manage the changelist and jumplist were also modified to
return mark types.
- get_jumplist -> fmark_T
- get_changelist -> fmark_T
The refactor is also seen mainly on normal.c, where all the mark
movement has been siphoned through one function nv_gomark, while the
other functions handle getting the mark and setting their movement
flags. To handle whether context marks should be left, etc.
** Mark View
While doing the refactor the concept of a mark view was also
implemented:
The view of a mark currently implemented as the number of lines between
the mark position on creation and the window topline. This allows for
moving not only back to the position of a mark but having the window
look similar to when the mark was defined. This is done by carrying and
extra element in the fmark_T struct, which can be extended later to also
restore horizontal shift.
*** User space features
1. There's a new option, jumpoptions+=view enables the mark view restoring
automatically when using the jumplist, changelist, alternate-file and
mark motions. <C-O> <C-I> g; g, <C-^> '[mark] `[mark]
** Limitations
- The view information is not saved in shada.
- Calls to get_mark should copy the value in the pointer since we are
using pos_to_mark() to wrap and provide a homogeneous interfaces. This
was also a limitation in the previous state of things.
Problem:
- Since c57f6b28d7#8519, sockets are created in ~/.local/… but XDG
spec says: "XDG_RUNTIME_DIR: Must be on the local filesystem", which
implies that XDG_STATE_DIR is potentially non-local.
- Not easy to inspect Nvim-created temp files (for debugging etc).
Solution:
- Store sockets in stdpath('run') ($XDG_RUNTIME_DIR).
- Establish "/tmp/nvim.user/" as the tempdir root shared by all Nvims.
- Make ok() actually useful.
- Introduce assert_nolog().
closes#3517closes#17093
Ref: 84f5463630
Rename:
- `underlineline` to `underdouble`
- `underdot` to `underdotted`
- `underdash` to `underdashed`
`underdouble` also now takes higher precedence than `undercurl`.
This fixes the following bugs:
`${1:else_text}` -> format with if_text: "else_text"
`${1:-else_text}` -> format with if_text: "else_text"
`${1:}` in `format` (eg. empty else_text) -> error.
`${1:}` (eg. empty placeholder) -> error.
Thanks hrsh7th :)
This is necessary in cases where filetype detection acts recursively.
For example, when matching files that end with .bak, the "root" of
the filename is matched again against the same buffer (e.g. a buffer
named "foo.c.bak" will be matched again with the filename "foo.c", using
the same underlying buffer).
This enables vim.filetype.match to match based on a buffer (most
accurate) or simply a filename or file contents, which are less accurate
but may still be useful for some scenarios.
When matching based on a buffer, the buffer's name and contents are both
used to do full filetype matching. When using a filename, if the file
exists the file is loaded into a buffer and full filetype detection is
performed. If the file does not exist then filetype matching is only
performed against the filename itself. Content-based matching does the
equivalent of scripts.vim, and matches solely based on file contents
without any information from the name of the file itself (e.g. for
shebangs).
BREAKING CHANGE: use `vim.filetype.match({buf = bufnr})` instead
of `vim.filetype.match(name, bufnr)`
Problem:
Nvim fails to create tempfile "…/nvim6UJx04/7" when 'shell' is set to
pwsh (PowerShell Core). This breaks filtered shell commands ":{range}!".
With shell set to cmd, it works.
Solution:
PowerShell doesn't use "<" for stdin redirection. Instead, use
"-RedirectStandardInput".
Closes#15913
This re-introduces the fix that the filetype.lua refactor inadvertently reverted.
The fix ensures that in the case when end_lnum is omitted, a string is always returned.
`nvim_get_option_value` and `nvim_set_option_value` better handle
unsetting local options. For instance, this is currently not possible:
vim.bo.tagfunc = nil
This does not work because 'tagfunc' is marked as "local to buffer" and
does not have a fallback global option. However, using :setlocal *does*
work as expected
:setlocal tagfunc=
`nvim_set_option_value` behaves more like :set and :setlocal (by
design), so using these as the underlying API functions beneath vim.bo
and vim.wo makes those two tables act more like :setlocal. Note that
vim.o *already* uses `nvim_set_option_value` under the hood, so that
vim.o behaves like :set.
The current emulation script enters Insert mode much too frequently.
Using only BufWinEnter seems to be a closer simulation.
Also add a few more mappings.
Steps to reproduce:
1. setting `vim.highlight.on_yank`
```
vim.api.nvim_create_autocmd({ "TextYankPost" }, {
pattern = { "*" },
callback = function()
vim.highlight.on_yank({ timeout = 200 })
end,
})
```
2. repeat typing `yeye` ...
3. causes the following error.
```
Error executing vim.schedule lua callback: vim/_editor.lua:0: handle 0x01e96970 is already closing
stack traceback:
[C]: in function 'close'
vim/_editor.lua: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
```
📝 Test result before fix:
[----------] Global test environment setup.
[----------] Running tests from test/functional/lua/highlight_spec.lua
[ RUN ] vim.highlight.on_yank does not show errors even if buffer is wiped before timeout: 15.07 ms OK
[ RUN ] vim.highlight.on_yank does not show errors even if executed between timeout and clearing highlight: 15.07 ms ERR
test/helpers.lua:73: Expected objects to be the same.
Passed in:
(string) 'Error executing vim.schedule lua callback: vim/_editor.lua:0: handle 0x02025260 is already closing
stack traceback:
[C]: in function 'close'
vim/_editor.lua: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>'
Expected:
(string) ''
Problem:
- Unix sockets are created in random /tmp dirs.
- /tmp is messy, unclear when OSes actually clear it.
- The generated paths are very ugly. This adds friction to reasoning
about which paths belong to which Nvim instances.
- No way to provide a human-friendly way to identify Nvim instances in
logs or server addresses.
Solution:
- Store unix sockets in stdpath('state')
- Allow --listen "name" and serverstart("name") to given a name (which
is appended to a generated path).
TODO:
- is stdpath(state) the right place?
Many filetypes from filetype.vim set buffer-local variables, meaning
vim.filetype.match cannot be used without side effects. Instead of
setting these buffer-local variables in the filetype detection functions
themselves, have vim.filetype.match return an optional function value
that, when called, sets these variables. This allows vim.filetype.match
to work without side effects.
Most LSP servers require the notification to correctly load the
settings and for those who don't it doesn't cause any harm.
So far this is done in lspconfig, but with the addition of vim.lsp.start
it should be part of core.
A alternative/subset of https://github.com/neovim/neovim/pull/18506 that should be forward compatible with a potential project system.
Configuration of LSP clients (without lspconfig) now looks like this:
vim.lsp.start({
name = 'my-server-name',
cmd = {'name-of-language-server-executable'},
root_dir = vim.fs.dirname(vim.fs.find({'setup.py', 'pyproject.toml'}, { upward = true })[1]),
})
Currently this is more or less a straight off reimplementation,
but this allow further optimizations down the line, especially
for avoiding memory allocations of rpc objects.
Current score for "make functionaltest; make oldtest" on a -DEXITFREE build:
is 117 055 352 xfree(ptr != NULL) calls (that's NUMBERWANG!).
When yanking another range while previous yank is still highlighted, the
pending timer could clear the highlight almost immediately (especially
when using larger `timeout`, i.e. 2000)
Fix a bug in lsp.buf.rename() where the range returned by the server in
textDocument/prepareRename was interpreted as a byte range directly,
instead of taking the negotiated offset encoding into account. This
caused the placeholder value in vim.ui.input to be incorrect in some
cases, for example when non-ascii characters are used earlier on the
same line.
Problem:
https://github.com/neovim/neovim/pull/18720#issuecomment-1142614996
The vim.health module is detected as a healthcheck, which produces spurious errors:
vim: require("vim.health").check()
========================================================================
- ERROR: Failed to run healthcheck for "vim" plugin. Exception:
function health#check, line 20
Vim(eval):E5108: Error executing lua [string "luaeval()"]:1: attempt to call field 'check' (a nil value)
stack traceback:
[string "luaeval()"]:1: in main chunk
Solution:
Skip vim.health when discovering healthchecks.
Also avoid referring to mappings as "keymaps" in commands and docs.
*map_empty_rhs* *map-empty-rhs*
You can create an empty {rhs} by typing nothing after a single CTRL-V (you
have to type CTRL-V two times). Unfortunately, you cannot do this in a vimrc
file.
- Complete function:
There was lots of unnecessary C code for the complete function, therefore
moving it to Lua and use all the plumbing we have in place to retrieve the
results.
- Moving the module:
It's important we keep nvim lua modules name spaced, avoids conflict with
plugins, luarocks, etc.
Currently the `title`, `message` and `percentage` is stored for a
progress, but there is also an optional `cancellable` that comes in with
both the `WorkDoneProgressBegin` and also `WorkDoneProgressReport`. This
change also stores that value so that a plugin can access it when they
do a lookup in `client.messages`.
Problem:
1. The main log routine does not protect itself against recursion.
log_lock() doesn't guard against recursion, it would deadlock...
2. 22b52dd462 (#11501) regressed 6f27f5ef91 (#10172), because
set_init_1..process_spawn tries to log (see backtrace below), but the
mutex isn't initialized yet. Even if the mutex were valid, we don't
want early logging to fallback to stderr because that can break
embedders when stdio is used for RPC.
frame 1: 0x00000001001d54f4 nvim`open_log_file at log.c:205:7
frame 2: 0x00000001001d5390 nvim`logmsg(log_level=1, context="UI: ", func_name=0x0000000000000000, line_num=-1, eol=true, fmt="win_viewport") at log.c:150:20
frame : 0x000000010039aea2 nvim`ui_call_win_viewport(grid=2, win=1000, topline=0, botline=1, curline=0, curcol=0, line_count=1) at ui_events_call.generated.h:321:3
frame 4: 0x00000001003dfefc nvim`ui_ext_win_viewport(wp=0x0000000101816400) at window.c:939:5
frame 5: 0x00000001003ec5b4 nvim`win_ui_flush at window.c:7303:7
frame 6: 0x00000001003a04c0 nvim`ui_flush at ui.c:508:3
frame 7: 0x00000001002966ba nvim`do_os_system(argv=0x0000600000c0c000, input=0x0000000000000000, len=0, output=0x0000000000000000, nread=0x00007ff7bfefe830, silent=false, forward_output=false) at shell.c:894:3
frame 8: 0x0000000100295f68 nvim`os_call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_args=0x0000000000000000) at shell.c:663:18
frame 9: 0x0000000100295845 nvim`call_shell(cmd="unset nonomatch; vimglob() { while [ $# -ge 1 ]; do echo \"$1\"; shift; done }; vimglob >/var/folders/gk/3tttv_md06987tlwpyp62jrw0000gn/T/nvimwwvwfD/0 ~foo", opts=kShellOptExpand | kShellOptSilent | kShellOptHideMess, extra_shell_arg=0x0000000000000000) at shell.c:712:14
frame 10: 0x0000000100294c6f nvim`os_expand_wildcards(num_pat=1, pat=0x00007ff7bfefeb20, num_file=0x00007ff7bfefee58, file=0x00007ff7bfefee60, flags=43) at shell.c:328:7
...
frame 23: 0x000000010028ccef nvim`expand_env_esc(srcp=",~foo", dst="~foo", dstlen=4094, esc=false, one=false, prefix=0x0000000000000000) at env.c:673:17
frame 24: 0x000000010026fdd5 nvim`option_expand(opt_idx=29, val=",~foo") at option.c:1950:3
frame 25: 0x000000010026f129 nvim`set_init_1(clean_arg=false) at option.c:558:19
frame 26: 0x00000001001ea25e nvim`early_init(paramp=0x00007ff7bfeff5f0) at main.c:198:3
frame 27: 0x00000001001ea6bf nvim`main(argc=1, argv=0x00007ff7bfeff848) at main.c:255:3
Solution:
1. Check for recursion, show "internal error" message.
- FUTURE: when "remote TUI" is merged, can we remove log_lock()?
2. Skip logging if log_init wasn't called yet.
Adds an `smods` key to `nvim_create_user_command` Lua command callbacks,
which has command modifiers but in a structured format. This removes the
need to manually parse command modifiers. It also reduces friction in
using `nvim_cmd` inside a Lua command callback.
Previously the `offset!` directive populated the metadata in such a way
that the new range could be attributed to a specific capture. #14046
made it so the directive simply stored just the new range in the
metadata and information about what capture the range is based from is
lost.
This change reverts that whilst also correcting the docs.
Previously, there was a bug where setting the local value of 'winbar' to
itself would cause winbar to appear on a floating window, which is
undesirable. This fix makes it so that it's explicitly required for the
window-local value of 'winbar' for a floating window to be set in order
for winbar to be shown on that window.
Problem: The terminal debugger uses various global variables.
Solution: Add a dictionary to hold the terminal debugger preferences.
c9a431c763
Omit popup menu.
The client state is cleaned up both in client.stop() as well as in the
client.on_exit() handler. Technically, the client has not actually
stopped until the on_exit handler is called, so we should just do this
cleanup there and remove it from client.stop().
This makes the common use case easier.
If one really needs access to all clients, they can create a filter
function which manually calls `get_active_clients`.
Neovim already removed `evim` (or any similar flags). The 'insertmode'
option is a weird remnant, so get rid of it.
The 'insertmode' option is replaced with a script that closely emulates
the option. This script is documented at :help 'insertmode'
Problem: smart/C/lisp indenting is optional, which makes the code more
complex, while it only reduces the executable size a bit.
Solution: Graduate FEAT_CINDENT, FEAT_SMARTINDENT and FEAT_LISP.
8e145b8246
The docs for `nvim_buf_set_extmark` mention that you can create a new
extmark when passing in `id=0`, however if you do this you'll get an
error since the code checks that id is positive.
```
id is not a positive integer
```
This change re-words the sentence to make it clearer.
The current approach of using `on_attach` callbacks for configuring
buffers for LSP is suboptimal:
1. It does not use the standard Nvim interface for driving and hooking
into events (i.e. autocommands)
2. There is no way for "third parties" (e.g. plugins) to hook into the
event. This means that *all* buffer configuration must go into the
user-supplied on_attach callback. This also makes it impossible for
these configurations to be modular, since it all must happen in the
same place.
3. There is currently no way to do something when a client detaches from
a buffer (there is no `on_detach` callback).
The solution is to use the traditional method of event handling in Nvim:
autocommands. When a LSP client is attached to a buffer, fire a
`LspAttach`. Likewise, when a client detaches from a buffer fire a
`LspDetach` event.
This enables plugins to easily add LSP-specific configuration to buffers
as well as enabling users to make their own configurations more modular
(e.g. by creating multiple LspAttach autocommands that each do
something unique).
Problem:
vim.lsp: require("vim.lsp.health").check()
========================================================================
- ERROR: Failed to run healthcheck for "vim.lsp" plugin. Exception:
function health#check, line 20
Vim(eval):E5108: Error executing lua ...m/HEAD-6613f58/share/nvim/runtime/lua/vim/lsp/health.lua:20: attempt to index a nil value
stack traceback:
...m/HEAD-6613f58/share/nvim/runtime/lua/vim/lsp/health.lua:20: in function 'check'
[string "luaeval()"]:1: in main chunk
Solution:
Check for nil.
fix#18602
