- eval.lua is now the source of truth.
- Formatting is much more consistent.
- Fixed Lua type generation for polymorphic functions (get(), etc).
- Removed "Overview" section from builtin.txt
- Can generate this if we really want it.
- Moved functions from sign.txt and testing.txt into builtin.txt.
- Removed the *timer* *timers* tags since libuv timers via vim.uv should be preferred.
- Removed the temp-file-name tag from tempname()
- Moved lueval() from lua.txt to builtin.txt.
* Fix indent
* fixup!
* fixup! fixup!
* fixup! better tag formatting
* fixup: revert changes no longer needed
* fixup! CI
---------
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
This aligns its behaviour better with `nvim_win_close`.
Note that `:hide` is actually incapable of closing the cmdwin, unlike `:close`
and `:quit`, so this is a bit of a difference in behaviour.
Problem: As discussed on Matrix, there was some interest in having
`nvim_open_win` again be able to open floats in the cmdwin (e.g: displaying a
hover doc related to what's in the cmdwin). After #23228, this was disallowed.
Solution: Allow `nvim_open_win` in the cmdwin as long as `!enter` and
`buffer != curbuf` (the former can cause all sorts of issues, and the latter
can crash Nvim after closing cmdwin). Also allow `nvim_win_set_buf` in a similar
fashion.
Note that we're not *entirely* sure if this is 100% safe (cmdwin is a
global-state-using-main-loop-calling beast), but this seems to work OK..?
Also:
- Check the buffer argument of `nvim_open_win` earlier, and abort if it's
invalid (it used to still open a window in this case).
- Untranslate `e_cmdwin` errors in the API (other errors in the API are not
translated: although not detailed in the API contract yet, errors are
supposed to be stable).
Problem: No test for bad use of spaces in help files.
Solution: Add checks for use of spaces in help files. Ignore intentional
spaces. (Hirohito Higashi, closesvim/vim#11952)
d950984489
Cherry-pick changes from patch 9.0.1604.
Co-authored-by: h-east <h.east.727@gmail.com>
Co-authored-by: Bram Moolenaar <Bram@vim.org>
* docs(lua): teach lua2dox how to table
* docs(lua): teach gen_vimdoc.py about local functions
No more need to mark local functions with @private
* docs(lua): mention @nodoc and @meta in dev-lua-doc
* fixup!
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
* perf(rtp): reduce rtp scans
Problem:
Scanning the filesystem is expensive and particularly affects
startuptime.
Solution:
Reduce the amount of redundant directory scans by relying less on glob
patterns and handle vim and lua sourcing lower down.
Problem:
Lua functions that return multiple results are declared by using
multiple `@return` docstring directives. But the generated docs don't
make it obvious what this represents.
Solution:
- Generate a "Return (multiple)" heading for multiple-value functions.
- Fix `@note` directives randomly placed after `@return`.
* feat(lua): allow vim.wo to be double indexed
Problem: `vim.wo` does not implement `setlocal`
Solution: Allow `vim.wo` to be double indexed
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Problem:
The parent commit added a new vim.get_visual_selection() function to
improve visual star. But that is redundant with vim.region(). Any
current limitations of vim.region() should be fixed instead of adding
a new function.
Solution:
Delete vim.get_visual_selection().
Use vim.region() to get the visual selection.
TODO: fails with visual "block" selections.
Problem:
Visual mode "*", "#" mappings don't work on text with "/", "\", "?", and
newlines.
Solution:
Get the visual selection and escape it as a search pattern.
Add functions vim.get_visual_selection and _search_for_visual_selection.
Fix#21676
Problem:
Sometimes, when nvim sends the `win_viewport` event, for example when scrolling
with visible folds on the screen, it reports the `scroll_delta` value one batch
into "future". So when the client application is trying to show the new viewport
it's not yet updated, resulting in temporary corruption / screen flickering.
For more details see #23609, and starting from [this comment](
https://github.com/neovide/neovide/pull/1790#issuecomment-1518697747) in
https://github.com/neovide/neovide/pull/1790,, where the issue was first
detected. Note that some of the conclusions in those are not fully accurate, but
the general observations are.
Solution:
When there are pending updates to a Window, delay the `win_viewport` UI event
until the updates are sent. This ensures that there's no flush between sending
the viewport and updating of the lines corresponding to the new viewport.
Document the existing viewport behaviour (for cases where there are no
extra flushes), give a hint about how applications can deal with the slightly
surprising behaviour of the viewport event being sent after the updates.
Fixes https://github.com/neovim/neovim/issues/23609
Problem: nvim_buf_set_text(), nvim_open_term() and termopen() all change buffer
text, which is forbidden during textlock. Additionally, nvim_open_term() and
termopen() may be used to convert the cmdwin buffer into a terminal buffer,
which is weird.
Solution: Allow nvim_buf_set_text() and nvim_open_term() in the cmdwin, but
disallow nvim_open_term() from converting the cmdwin buffer into a terminal
buffer. termopen() is not allowed in the cmdwin (as it always operates on
curbuf), so just check text_locked().
Also happens to improve the error in #21055: nvim_buf_set_text() was callable
during textlock, but happened to check textlock indirectly via u_save();
however, this caused the error to be overwritten by an unhelpful "Failed to
save undo information" message when msg_list == NULL (e.g: an `<expr>` mapping
invoked outside of do_cmdline()).
