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
Updated runtime files.
03413f4416
Ignore changes to
* doc/Makefile, doc/help.txt: Related to Vim's version8 documentation
* doc/gui_x11.txt, doc/todo.txt, doc/vim.1, gvim.desktop, vim.desktop:
Irrelevant to Neovim
* doc/quickref.txt, doc/options.txt: As of yet unported 'emoji'
* doc/tags, syntax/vim.vim: Generated at build time
Updated runtime files
dae8d21dd2
Ignore changes to
* doc/eval.txt: Channel related docs
* doc/help.txt, doc/index.txt, doc/os_390.txt: Removal of obsolete features, which
already happened in Neovim
* doc/tags: Generated at build time
* doc/todo.txt, doc/version5.txt: Irrelevant to Neovim
Updated runtime files.
acb4f221c7
Ignored changes to:
* doc/eval.txt since alloc_fail isn't relevant for neovim
* doc/index.txt for unmerge :smile command
* doc/tags, syntax/vim.vim since they're generated at build time
* doc/todo.txt
It's not documentation in the same sense as the majority of files in
runtime/doc, so is of little use to most users and should probably not
be installed alongside the "real" documentation.
It may be full of good ideas, but it's also full of things which are no
longer applicable to Nvim, such as references to platforms we no longer
support (e.g., MS-DOS), Vi compatibility, Autoconf, the Perl interface,
etc.
If someone is looking for things to fix or improve, the GitHub issue
tracker should prove useful, and, unlike todo.txt, the issues are
generally much more relevant to Nvim. Besides all that, removing
todo.txt makes porting runtime patches a bit easier.
refs #2911, discussed briefly in #2608 and #2553
All of this information is a combination of incorrect, outdated, or
redundant given its availability in other help files.
Reviewed-by: Justin M. Keyes <justinkz@gmail.com>
Reviewed-by: Felipe Morales <hel.sheep@gmail.com>
