| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| | |
|
| |
|
|
| |
Most of the lsp.log will be addressed in a separate PR.
|
| |
|
|
|
| |
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.
|
