| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
The name `README_template.md` is confusing, because it is not related to
the README (that changed long ago).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
| |\
| |
| | |
feat(angular-ls): add angular language service
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
https://github.com/neovim/nvim-lsp/issues/220
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
notification
related with #127
|
| |
|
|
|
| |
Since 6d380677502d, configs are lazy-loaded. So docgen.lua needs to
require() them explicitly.
|
| |
|
|
| |
- mention :packadd
- more renames
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`nvim_lsp/skeleton.lua` is not really a skeleton, it's a `configs`
class that provides
1. actual functionality
2. a bunch of configs
Each config is added to the `configs` object (FKA "skeleton") as
a property. Those configs are not "templates", they are "configs". So we
should clean up the wording in various places to say "config" instead of
"skeleton"/"template".
Closes #64
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Lua is easy to use from Vimscript, there is no reason to have multiple
ways to work with nvim-lsp.
- massively clarifies the "story" that users need to comprehend
- reduces surface area, maintenance, tests
- avoids constant "Vim or Lua" dance in the documentation
- simplifies discussions, tutorials, etc.
- avoids confusing situation for users that start with Vimscript but
later need Lua-only features
|
| | |
|
| |
|
|
| |
- Add client.workspace_did_change_configuration()
- Notify settings on init.
|
| | |
|
| |
|
