logically infinite. Therefore some |vim.iter| operations (e.g.
|Iter:rev()|) make sense only on list-like tables (which are finite by
definition).

                                                           *lua-function-call*
Lua functions can be called in multiple ways. Consider the function: >lua
    local foo = function(a, b)
        print("A: ", a)
        print("B: ", b)
    end

The first way to call this function is: >lua
    foo(1, 2)
    -- ==== Result ====
    -- A: 1
    -- B: 2

This way of calling a function is familiar from most scripting languages. In
Lua, any missing arguments are passed as `nil`, and extra parameters are
silently discarded. Example: >lua
    foo(1)
    -- ==== Result ====
    -- A: 1
    -- B: nil
<
                                                                      *kwargs*
When calling a function, you can omit the parentheses if the function takes
exactly one string literal (`"foo"`) or table literal (`{1,2,3}`). The latter
is often used to mimic "named parameters" ("kwargs" or "keyword args") as in
languages like Python and C#. Example: >lua
    local func_with_opts = function(opts)
        local will_do_foo = opts.foo
        local filename = opts.filename
        -- ...
    end

    func_with_opts { foo = true, filename = "hello.world" }
<
There's nothing special going on here except that parentheses are implicitly
added. But visually, this small bit of sugar gets reasonably close to a
"keyword args" interface.

                                                                   *lua-regex*
Lua intentionally does not support regular expressions, instead it has limited
|lua-pattern|s which avoid the performance pitfalls of extended regex. Lua
scripts can also use Vim regex via |vim.regex()|.

Examples: >lua

    print(string.match("foo123bar123", "%d+"))
    -- 123
    print(string.match("foo123bar123", "[^%d]+"))
    -- foo
    print(string.match("foo123bar123", "[abc]+"))
    -- ba
    print(string.match("foo.bar", "%.bar"))
    -- .bar

==============================================================================
IMPORTING LUA MODULES                                        *lua-module-load*

Modules are searched for under the directories specified in 'runtimepath' and
|packages-runtimepath|, in the order they appear in the output of this command
>vim
	:echo nvim_list_runtime_paths()
<
Any "." in the module name is treated as a directory separator when searching.
For a module `foo.bar`, each directory is searched for `lua/foo/bar.lua`, then
`lua/foo/bar/init.lua`.  If no files are found, the directories are searched
again for a shared library with a name matching `lua/foo/bar.?`, where `?` is
a list of suffixes (such as `so` or `dll`) derived from the initial value of
|package.cpath|. If still no files are found, Nvim falls back to Lua's default
search mechanism. The first script found is run and `require()` returns the
value returned by the script if any, else `true`.

The return value is cached after the first call to `require()` for each module,
with subsequent calls returning the cached value without searching for, or
executing any script. For further details see |require()|.

For example, if 'runtimepath' is `foo,bar` and |package.cpath| was
`./?.so;./?.dll` at startup, `require('mod')` searches these paths in order
and loads the first module found ("first wins"): >
    foo/lua/mod.lua
    foo/lua/mod/init.lua
    bar/lua/mod.lua
    bar/lua/mod/init.lua
    foo/lua/mod.so
    foo/lua/mod.dll
    bar/lua/mod.so
    bar/lua/mod.dll
<
Note:

- Although 'runtimepath' is tracked, Nvim does not track current
  values of |package.path| or |package.cpath|. If you happen to delete some
  paths from there you can set 'runtimepath' to trigger an update: >vim
      let &runtimepath = &runtimepath

- Skipping paths from 'runtimepath' which contain semicolons applies both to
  |package.path| and |package.cpath|. Given that there are some badly written
  plugins using shell, which will not work