Problem:
If a config throws an error it fails the entire doc generation.
Solution:
Handle config error in docgen. Unfortunately, this doesn't show the
error message, it shows:
loop or previous error loading module 'lsp.volar'
instead of the actual `error('…')` message.
So meanwhile, document the current deprecation/rename pattern and use
`vim.notify()` instead.
Problem:
Since configs now live in `lsp/`, the docgen needs to be updated.
Solution:
Read the configs from `lsp/`. Parse the `@brief` docstring to get the
docs.
Problem:
When `root_dir` is not defined as a function, the generated docs show
the paths resolved in the CI env:
root_dir : lua "/home/runner/work/nvim-lspconfig/nvim-lspconfig"
Solution:
Always show the "gF" message for `root_dir`, even if it is not
a function.
Fix#3628
Problem:
debug.info() is useless for some functions because they point to util.lua
Solution:
Provide a path to the source code instead of trying to inline the source
code.
Problem:
Docs are manually maintained everywhere for no good reason.
Solution:
- revert commit 9dc02492c4a457479f8a0ec7a65aac1852ff59c0
- provide a "gF" friendly link to the source
Problem:
Users/plugins may want to use the config definition without actually
activating the config via setup().
Solution:
- Expose `config_def` field and document it.
- Also undeprecate some stuff that doesn't yet have a documented
alternative.
TODO: configs.lua sets `M.filetypes = config.filetypes` and other fields
in ad-hoc fashion "for :LspInfo" but it's not clear when those fields
are actually populated, and they don't source from `config_def`...
Problem:
The name `server_configurations` is extremely verbose and irritatingly
formal and dogmatic. This overlong name is a constant nuisance when
reading, writing, and coding.
It's also not even correct: these configurations are just as much
"client" configurations as they are "server" configurations.
Solution:
- Rename to a shorter name.
- Leave placeholder files for any old URLs that link to the old
location.
* docs: make sure username doesn't leak into generated document
The documents previously contained `runner`, the username of GitHub
Actions runners, which would be overwritten by the user's name when run
locally and generate unwanted diff.
* docs: rename username to user
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
---------
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
The recently added rockspec (see #2307) has to be prepared and
uploaded to luarocks for each release.
This adds an automated workflow for it, which has been tested with
plenary.nvim.
To be able to upload to luarocks, the owner of the luarocks account
will have to add an API key named `LUAROCKS_API_KEY` to this repo's
GitHub Actions secrets.
Problem:
- The docs are verbose.
- The "settings" param is not really clarified anywhere.
Solution:
- Mention the "settings" param in the README.
- Tighten up the wording.
- Remove the "Use a loop to conveniently call 'setup'..." advice in the
docs. It confuses users and doesn't really save much code.
- Start to reduce the scope of nvim-lspconfig.
- For example, it is redundant for it to document general LSP things.
Thus, the help section *lspconfig-lsp* was removed.
closes#1951
Most plugin managers run :helptags in the plugin, which silently
overwrites the existing doc/tags. this is an issue for us since lspconfig
is manipulating the tags file to point to servers_configurations.md
Instead create a markdown comment with the name of the wanted tag and
make a copy in the repository of servers_configurations.md to
server_configurations.txt. Now when :helptags runs it finds the txt file
and generates the appropriate tag.
The advantage is this solution should work in all platforms, it also
removes lines from docgen CI.
* generating the tags at docgen and modifying the
|lspconfig-server-configurations|
tag allows `:help lspconfig-server-configurations` take you to
./doc/server_configurations.md
* adding a modeline to the markdown file ensures it sets the
correct filetype
Co-authored-by: Javier López <graulopezjavier@gmail.com>