Problem: cache paths are derived by replacing each reserved/filesystem-
path-sensitive char with a `%` char in the original path. With this
method, two different files at two different paths (each containing `%`
chars) can erroneously resolve to the very same cache path in certain
edge-cases.
Solution: derive cache paths by url-encoding the original (path) instead
using `vim.uri_encode()` with `"rfc2396"`. Increment `Loader.VERSION` to
denote this change.
* 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>
closes https://github.com/neovim/neovim/issues/15261
* normalize uri path to forward slashes on windows
* use a capture group on windows that avoids mistaking drive letters as uri scheme
The official developer documentation in in :h dev-lua-doc specifies to
use "--@" for special/magic tokens. However, this format is not
consistent with EmmyLua notation (used by some Lua language servers) nor
with the C version of the magic docstring tokens which use three comment
characters.
Further, the code base is currently split between usage of "--@",
"---@", and "--- @". In an effort to remain consistent, change all Lua
magic tokens to use "---@" and update the developer documentation
accordingly.
RFC 8089, which defines the file URI scheme, also allows URIs without a
hostname, i.e. of the form file:/path/to/file. These are returned by
some language servers and accepted by other LSP implementations, such as
VSCode's, so it is reasonable for us to accept them as well.
* Change uri_to_fname to not convert non-file URIs
A URI with a scheme other than file doesn't have a local file path.
* fixup! Change uri_to_fname to not convert non-file URIs
* fixup! fixup! Change uri_to_fname to not convert non-file URIs
Mainly configuration and RPC infrastructure can be considered "done". Specific requests and their callbacks will be improved later (and also served by plugins). There are also some TODO:s for the client itself, like incremental updates.
Co-authored by at-tjdevries and at-h-michael, with many review/suggestion contributions.
