`vim.health` is not a "plugin" but part of our Lua API and the
documentation should reflect that. This also helps make the
documentation maintenance easier as it is now generated.
Problem: Wiki contents are not discoverable and hard to maintain.
Solution: Move FAQ to runtime docs.
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Enforce consistent terminology (defined in
`gen_help_html.lua:spell_dict`) for common misspellings.
This does not spellcheck English in general (perhaps a future TODO,
though it may be noisy).
Add introductory guide explaining how to use Lua in Neovim:
where to put Lua files, how to set variables and options, how
to create mappings, autocommands, and user commands.
Adapted with kind permission from
https://github.com/nanotee/nvim-lua-guide
based on http://www.vim.org/scripts/script.php?script_id=1291
reformatted to match Nvim documentation style; removed irrelevant sections
Co-authored-by: dundargoc <gocundar@gmail.com>
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Problem: The eval.txt help file is way too big.
Solution: Move the builtin function details to a separate file.
1cae5a0a03
Note: Neovim-specific references to |functions| were changed to
|builtin-functions|. This included updates to:
1. test/functional/vimscript/functions_spec.lua
2. test/functional/vimscript/eval_spec.lua
3. runtime/doc/lua.txt
Problem: The eval.txt help file is too big.
Solution: Split off testing support to testing.txt. Move function details
to where the functionality is explained.
ed997adaa1
Vim commit 5477506a9f01d40fad2e8f0555bc37adee30478f
contains the duplicate tag fix in runtime/doc/testing.txt.
- remove redundant autocmd list
This "grouped" list is useless, it only gets in the way when searching
for event names.
- intro.txt: cleanup
- starting.txt: update, revisit
- doc: `:help bisect`
- mbyte.txt: update aliases 1656367b90. closes#11960
- options: remove 'guifontset'. Why:
- It is complicated and is used by almost no one.
- It is unlikely to be implemented by Nvim GUIs (complicated to parse,
specific to Xorg...).
Asynchronous API functions are served immediately, which means pending
input could change the state of Nvim shortly after an async API function
result is returned.
nvim_get_mode() is different:
- If RPCs are known to be blocked, it responds immediately (without
flushing the input/event queue)
- else it is handled just-in-time before waiting for input, after
pending input was processed. This makes the result more reliable
(but not perfect).
Internally this is handled as a special case, but _semantically_ nothing
has changed: API users never know when input flushes, so this internal
special-case doesn't violate that. As far as API users are concerned,
nvim_get_mode() is just another asynchronous API function.
In all cases nvim_get_mode() never blocks for more than the time it
takes to flush the input/event queue (~µs).
Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if
e.g. `d` is operator-pending.
Closes#6159
