| Age | Commit message (Collapse) | Author | Files |
|---|
|
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`.
|
|
Use the wording from the wait() Vimscript function.
|
|
Problem:
Using vim.defer_fn() just before Nvim exit leaks luv handles.
Solution:
Make vim.schedule() return an error message if scheduling failed.
Make vim.defer_fn() close timer if vim.schedule() failed.
|
|
Problem: Fast context for msg_show event inhibits vim.ui_attach from
displaying a stream of messages from a single command.
Solution: Remove fast context from msg_show events emitted as a result
of explicit API/command calls. The fast context was originally
introduced to prevent issues with internal messages.
|
|
fix https://github.com/neovim/neovim/issues/36858
|
|
Problem:
After bc0635a9fc9c15a2423d4eb35f627d127d00fa46 `vim.wait()` rejects floats
and NaN values.
Solution:
Restore the prior behavior, while still supporting `math.huge`. Update
tests to cover float case.
|
|
Close #35926
Close #35818
Co-authored-by: skewb1k <skewb1kunix@gmail.com>
Co-authored-by: glepnir <glephunter@gmail.com>
|
|
Problem:
The callback passed to `vim.wait` cannot return results directly, it
must set upvalues or globals.
local rv1, rv2, rv3
local ok = vim.wait(200, function()
rv1, rv2, rv3 = 'a', 42, { ok = { 'yes' } }
return true
end)
Solution:
Let the callback return values after the first "status" result.
local ok, rv1, rv2, rv3 = vim.wait(200, function()
return true, 'a', 42, { ok = { 'yes' } }
end)
|
|
Problem: Cmdline buffer is not cleared for a new message (since c973c7ae),
resulting in an incorrect spill indicator. When the cmdline
buffer is cleared, "msg_row" is not invalidated, resulting in
an error. The extui module is untested.
Return value of `vim.ui_attach()->callback` is undocumented.
Solution: Clear the cmdline buffer for the first message in an event
loop iteration. Ensure msg_row passed as end_row does not
exceed buffer length.
Add `messages_spec2.lua` to test the extui module, keeping in
mind that test coverage will greatly increase if this UI is made
the default. As such, only tests for specific extui functionality
unlikely to be covered by tests leveraging the current message grid.
Document the return value of `vim.ui_attach()->callback`, it seems
to make sense, and is also used to suppress remote UI events in
`messages_spec2.lua`.
|
|
Problem: We allow setting 'cmdheight' to 0 with ext_messages enabled
since b72931e7. Enabling ext_messages with vim.ui_attach()
implicitly sets 'cmdheight' to 0 for BWC. When non-zero
'cmdheight' is wanted, this behavior make it unnecessarily
hard to keep track of the user configured value.
Solution: Add set_cmdheight to vim.ui_attach() opts table that can be
set to false to avoid setting 'cmdheight' to 0.
|
|
|
|
Problem: Prompts are emitted as messages events, where cmdline events
are more appropriate. The user input is also emitted as
message events in fast context, so cannot be displayed with
vim.ui_attach().
Solution: Prompt for user input through cmdline prompts.
|
|
Problem: No longer able to show prompt messages with vim.ui_attach().
Solution: Do not execute callback in fast context for prompt message
kinds. These events must be safe to show the incoming message
so the event itself serves to indicate that the message
should be shown immediately.
|
|
Problem: Lua callbacks for "msg_show" events with vim.ui_attach() are
executed when it is not safe.
Solution: Disallow non-fast API calls for "msg_show" event callbacks.
Automatically detach callback after excessive errors.
Make sure fast APIs do not modify Nvim state.
|
|
PROBLEM:
There are several limitations to vim.str_byteindex, vim.str_utfindex:
1. They throw given out-of-range indexes. An invalid (often user/lsp-provided)
index doesn't feel exceptional and should be handled by the caller.
`:help dev-error-patterns` suggests that `retval, errmsg` is the preferred
way to handle this kind of failure.
2. They cannot accept an encoding. So LSP needs wrapper functions. #25272
3. The current signatures are not extensible.
* Calling: The function currently uses a fairly opaque boolean value to
indicate to identify the encoding.
* Returns: The fact it can throw requires wrapping in pcall.
4. The current name doesn't follow suggestions in `:h dev-naming` and I think
`get` would be suitable.
SOLUTION:
- Because these are performance-sensitive, don't introduce `opts`.
- Introduce an "overload" that accepts `encoding:string` and
`strict_indexing:bool` params.
```lua
local col = vim.str_utfindex(line, encoding, [index, [no_out_of_range]])
```
Support the old versions by dispatching on the type of argument 2, and
deprecate that form.
```lua
vim.str_utfindex(line) -- (utf-32 length, utf-16 length), deprecated
vim.str_utfindex(line, index) -- (utf-32 index, utf-16 index), deprecated
vim.str_utfindex(line, 'utf-16') -- utf-16 length
vim.str_utfindex(line, 'utf-16', index) -- utf-16 index
vim.str_utfindex(line, 'utf-16', math.huge) -- error: index out of range
vim.str_utfindex(line, 'utf-16', math.huge, false) -- utf-16 length
```
|
|
An implication of this current approach is that `NVIM_API_LEVEL` should be
bumped when a new Lua function is added.
TODO(future): add a lint check which requires `@since` on all new functions.
ref #25416
|
|
Some composite/compound types even as basic as `(string|number)[]` are
not currently supported by the luacats LPEG grammar used by gen_vimdoc.
It would be parsed & rendered as just `string|number`.
Changeset adds better support for these types.
|
|
|
|
|
|
Co-authored-by: ite-usagi <77563904+ite-usagi@users.noreply.github.com>
Co-authored-by: v-sim <56476039+v-sim@users.noreply.github.com>
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Quico Augustijn <quico.public@gmail.com>
Co-authored-by: nhld <nahnera@gmail.com>
Co-authored-by: francisco souza <108725+fsouza@users.noreply.github.com>
|
|
|
|
|
|
- Added `@inlinedoc` so single use Lua types can be inlined into the
functions docs. E.g.
```lua
--- @class myopts
--- @inlinedoc
---
--- Documentation for some field
--- @field somefield integer
--- @param opts myOpts
function foo(opts)
end
```
Will be rendered as
```
foo(opts)
Parameters:
- {opts} (table) Object with the fields:
- somefield (integer) Documentation
for some field
```
- Marked many classes with with `@nodoc` or `(private)`.
We can eventually introduce these when we want to.
|
|
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
|
|
|
|
|
|
`vim.wait()` cannot be called in a fast callback since the main loop
cannot be run in that context as it is not reentrant
Fixes #26122
|
|
Per https://github.com/neovim/neovim/pull/25286#discussion_r1332861721
and https://github.com/neovim/neovim/pull/25286#discussion_r1334318352
|
|
|
|
|
|
Closes #24422
|
|
|
|
|
|
|
|
|
|
|
