Problem: Currently, vim.notify is only used to display messages when the
message type is Error.
Solution: Use vim.notify to display messages for all message types.
feat(logs): show full path of short_src in lsp logs
Problem:
- Cannot gf to info.short_src printed in the logs since only the last 16
characters are printed
Solution:
- Print full info.short_src and remove ...
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of 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>
- fix lint / analysis warnings
- locations_to_items(): get default offset_encoding from active client
- character_offset(): get default offset_encoding from active client
* Simplify rpc encode/decode messages to rpc.send/rcp.receive
* Make missing handlers message throw a warning
* Clean up formatting style in log
* Move all non-RPC loop messages to trace instead of debug
* Add format func option to log to allow newlines in per log entry
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.
If vim.lsp.log is loaded the second time,
the vim.log.levels will be modified with additional
entries from 0-5.
This will cause the require to fail as level:lower does
not exists on numbered value.
Adds function to notify the user like this:
`:lua vim.notify("hello user")`
embeds log levels vim.log.levels.
you can then reassign vim.notify to for instance
```
function notify_external(msg, log_level, opts)
vim.fn.jobstart({"notify-send", msg })
end
```
while there is some controversy, stdpath('cache') looks like a better fit for logs than stdpath('data'): you can remove logs without preventing nvim to work which fits the XDG_CACHE_HOME definition of `user specific non-essential data files`.
It's confusing because vim-lsp already has the same name as the plugin name that predates this built-in lsp.
Also, since "vim.fn.stdpath" is used, adding the prefix "nvim-" is redundant, so just "lsp.log" will suffice.
According to the LSP specification, showMessage is what is displayed and logMessage is what is stored.
Since these are different things, I devide the callback into those that match.
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.
