Commit Graph

14 Commits

Author SHA1 Message Date
zeertzjq
268cd370be vim-patch:595d0a7: runtime(doc): wrong {str} length limit in matchfuzzy() docs (#40157)
Problem:  docs say {str} is capped at 256 and longer returns an empty list.
Solution: it's 1024, and {str} plus each candidate are just truncated to
          that, not rejected; fix the text.

closes: vim/vim#20453

595d0a77e4

Co-authored-by: glepnir <glephunter@gmail.com>
2026-06-10 01:18:26 +00:00
Justin M. Keyes
8f584031bc docs: misc #40126 2026-06-08 16:12:14 -04:00
Justin M. Keyes
cbadc4f164 docs: misc, lsp
Problem:
This doc on `vim.lsp.completion.get()`:

    --- Used by the default LSP |omnicompletion| provider |vim.lsp.omnifunc()|, thus |i_CTRL-X_CTRL-O|
    --- invokes this in LSP-enabled buffers. Use CTRL-Y to select an item from the completion menu.
    --- |complete_CTRL-Y|

...makes two wrong claims:

1. "Used by the default LSP omnicompletion provider vim.lsp.omnifunc()"
    - `_omnifunc` does not call `M.get()`, it calls the internal `trigger()` directly.
2. "thus |i_CTRL-X_CTRL-O| invokes this in LSP-enabled buffers"
    - The two paths use different client sets:
        - `M.get()` reads `buf_handles[bufnr].clients` (clients
          explicitly registered via `vim.lsp.completion.enable(true, ...)`).
        - `_omnifunc` reads `lsp.get_clients({method='textDocument/completion'})` (every
          completion client, regardless of `enable()`).

Solution:
Update docs.

Co-authored-by: Koichi Shiraishi <zchee.io@gmail.com>
Co-authored-by: y9san9 / Alex Sokol <y9san9@gmail.com>
Co-authored-by: adv0r <>
2026-06-03 12:27:30 +02:00
zeertzjq
edcaf1887a vim-patch:partial:9.2.0573: Vim9: missing EX_WHOLE on some block keywords (#40071)
Problem:  Several Vim9 keywords lack EX_WHOLE and can be shortened in
          Vim9 script, inconsistent with endif/enddef/endfor/endwhile/
          endtry which already have it.  The error from :endd in a
          nested function also hardcodes "enddef" instead of reporting
          what the user typed.  fullcommand("ho") returns "horizontal"
          even though :ho is below the documented 3-char minimum.
Solution: Add EX_WHOLE to :class, :def, :endclass, :endinterface,
          :endenum, :public and :static.  In get_function_body() pass
          the user-typed command to the error message.  Force :ho to
          CMD_SIZE in find_ex_command() so fullcommand() reflects the
          modifier minimum.  Extend tests and documentation accordingly
          (Peter Kenny).

fixes:  vim/vim#20032
closes: vim/vim#20191

38d9a16eba

Co-authored-by: Peter Kenny <github.com@k1w1.cyou>
2026-06-01 01:04:30 +00:00
Justin M. Keyes
e572c9c80a feat(api): tab-local option scope #39811
Problem:
2d795face6 added support for tab-local options ('cmdheight')
to `nvim_get_option_value`, but not to:

    nvim_get_option_info2()
    nvim_set_option_value(…, { tab = … })
    gettabwinvar()

Solution:
- Update `options.lua` to model tab-local options. Introduce `kOptScopeTab`.
- Handle tab scope in the options layer so it works for all options APIs.

Note:
- No change to `gettabvar()`. Not sure if needed/wanted.

fix https://github.com/neovim/neovim/issues/31140
2026-05-17 10:24:46 -04:00
Justin M. Keyes
1f4ad7808e docs: misc, window #39720
- formalize `window-number` similar to `tabpage-number`.
- reference it from docs.
2026-05-10 13:00:52 -04:00
Szymon Wilczek
3639f7a867 feat(server): add v:useractive, use it in serverlist(info=true) #39423
Problem:
When showing the :connect menu, it is useful to know which servers
are most-recently active. But we don't have a good way to detect that.

Solution:
- Introduce `v:useractive`.
- Include this timestamp in `serverlist({info=true})`.

Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com>
2026-05-07 10:47:51 -04:00
Justin M. Keyes
662c556a3e docs: rename "tabpage" 2026-05-07 10:36:55 +02:00
Szymon Wilczek
c3f803c3b6 feat(server): serverlist({info=true}) gets detailed info #39392
Problem:
UI tools and orchestration engines need more context than just raw
socket addresses from serverlist(). Without knowing if a server belongs
to the current instance or knowing its PID, UIs cannot display
meaningful options to users.

Solution:
- Added the `info=v:true` option to `serverlist()`.
- When `info` is requested, it implies `peer=true` and returns a list of
  dictionaries (defined as `vim.ServerInfo`) with `addr`, `pid` and
  `own`.
- Uses an RPC request to `getpid()` across the socket to fetch the
  peer's actual process ID.

Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com>
2026-05-06 08:55:34 -04:00
Lewis Russell
aeba27f37b feat(doc): document Lua alternative for vim.fn
AI-assisted: Codex
2026-04-27 09:06:11 +01:00
Justin M. Keyes
b70224e3bd docs: misc #39256 2026-04-25 11:16:18 -04:00
Justin M. Keyes
0d4d285bd2 perf(vim.fn): call Lua-implemented vim.fn.xx() directly #39166
Problem:
- Builtin "Vimscript" functions (f_xx) are mostly implemented in C.
  Partly that's because there is some boilerplate required to call out
  to Lua.
- Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript
  ("typval") bridge, even if `fn.foo()` is implemented entirely in Lua:
  ```
  Lua => typval => Object => Lua => Object => typval => Lua.
  ```

Solution:
Functions declared in eval.lua with `func_lua` are implemented in
entirely in Lua (`_core/vimfn.lua`).

- `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles
  the typval conversion for Vimscript callers (slow path).
- `nlua_call()` detects `func_lua` functions and calls the Lua
  implementation directly. This eliminates all conversion overhead for
  Lua callers (fast path).
- Validate at build-time that `func`, `func_float`, and `func_lua` are
  mutually exclusive.
- Migrate `hostname()` as a toy example, to show the idea.
2026-04-17 19:10:20 -04:00
zeertzjq
39410ef42b vim-patch:8.2.2440: documentation based on patches is outdated (#39144)
Problem:    Documentation based on patches is outdated.
Solution:   Add changes to documentation in a patch.

853886722c

Trailing space was removed in later patches.
Also fix a few more misplaced error numbers from #8155.

Co-authored-by: Bram Moolenaar <Bram@vim.org>
2026-04-17 09:50:03 +08:00
Justin M. Keyes
65b40e69ac fix(lua): not obvious which _meta/ files are generated #39035
Problem:
- Not obvious which _meta/ are generated and which should be edited
  manually.
- The require guard (`error('Cannot require a meta file')`) is not
  consistently present in all meta files.

Solution:
- Update headers.
- Add require() guard to all meta files.
- Rename generated meta files with `.gen.lua`.
2026-04-14 05:38:47 -04:00