-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
ale
Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
which-key.nvim
💥 Create key bindings that stick. WhichKey is a lua plugin for Neovim 0.5 that displays a popup with possible keybindings of the command you started typing.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I understand the frustration (making neovim more cohesive is definitely a goal). It sounds like coc provides the UI you are used to, so there's no harm in sticking with that!
Many of our users explicitly don't want automatically called functions that would slow down the editor (autocommands that map signature requests to the language server, for example), so by nature neovim's core implementation is extremely conservative.
One thing I would like to do, is make the automatic pop-ups for signature easier to implement with our current handler, which means a plugin like signature-x could use our upcoming lsp.config option to configure it's borders (https://github.com/neovim/neovim/pull/14681), and match the rest of the UI.
I also have another project I was working on before the 0.5 stabilization phase (https://github.com/mjlbach/neovim-ui). The goal with this is to have composable/overridable UI elements built into core (which we would use for our internal lsp functions), that can be used (or overridden) by UI plugins.
In summary, I think the likelihood of autocompletion (and generally auto-anything) being built-into core is very small, but providing the APIs in neovim core to make snippets - autocompletion - automated UI elements easier for plugin authors is a high priority.
I tried nvim-compe, but it explicitly doesn't support signatures (see https://github.com/hrsh7th/nvim-compe#does-not-work-function... ). So I installed the recommended lsp_signature.nvim and it's a bit of a mess. The UI for lsp_signature has enormous borders and doesn't match at all with the rest of compe.
Perhaps there are ways to tweak lsp_signature UI... but at this point, I chucked it all and went back to coc.nvim which does it all (suggestions, signatures, etc.) all with the same UI.
Make it like that--make it work with all UI out of the box and not make me dig through tons of plugins. That's my honest suggestion.
LunarVim: A Neovim config made with sane defaults https://github.com/ChristianChiarulli/LunarVim
LunarVim will be like Spacemacs/Doom Emacs, but for neovim.
This project is still at its early stage and many things change rapidly. You currently cannot easily keep your custom changes in sync with LunarVim, but support for this feature is on the way.
In a few months this project should be stable enough for typical users.
I talked about the configuration in my videos (linked above).
The best place to start is here: https://github.com/neovim/nvim-lspconfig
I use it in combination with nvim-compe: https://github.com/hrsh7th/nvim-compe
For those out there trying to "learn" vim, give neovim 0.5 a try!
I've been using neovim HEAD (0.5 pre-release) for a while and it has been awesome. It all started with this config [0] and from there and haven't tried (as before) to join a vim cult but instead to use it as a tool that works for me (i.e. use mouse scroll to browse around, use arrows on insert mode, and other vim sins)
Little by little I've been looking at how I could do something a little better and pretty much every time vim has an awesome way for me to do something! Yanked some text then deleted something but I want to paste the yanked text, not the deleted one? "0p is the answer. Need to replace all ___ but not modify the prefixed numbers? I can use visual regex to easily work that out! I'm doing something over and over? I can make that into a macro! There's a macro that I always use on certain file types? I can make an autocmd to load some string to some macro when I open certain file.
It'a awesome feeling that time I've actually learning about registers, macros, regex, windows, buffers, and everything else in a modern and snappy tool!
[0] https://github.com/mjlbach/defaults.nvim
There's a few really cool things. The built in LSP is pretty clean compared to clunky nodejs or python plugins which I've found to clog down on huge codebases. The syntax engine has been improved by a tree-sitter algo, so it's way more robust with the syntax hilighting. And while I haven't messed with this yet you can do the whole config file in Lua now, which sounds pretty powerful.
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
https://github.com/nvim-telescope/telescope.nvim
There is a middle ground for VS Code users:
https://github.com/asvetliakov/vscode-neovim
This extension integrates neovim into the VS Code environment by mapping keystrokes from VS Code to the neovim binary. This approach (which requires 0.5) is much simpler and more robust than attempting to emulate all of VIM, as the VSCodeVIM extension does.
If anyone is interested in migrating their config to lua, or doing some basic scripting, there's an excellent and pretty comprehensive guide here: https://github.com/nanotee/nvim-lua-guide
I understand the frustration (making neovim more cohesive is definitely a goal). It sounds like coc provides the UI you are used to, so there's no harm in sticking with that!
Many of our users explicitly don't want automatically called functions that would slow down the editor (autocommands that map signature requests to the language server, for example), so by nature neovim's core implementation is extremely conservative.
One thing I would like to do, is make the automatic pop-ups for signature easier to implement with our current handler, which means a plugin like signature-x could use our upcoming lsp.config option to configure it's borders (https://github.com/neovim/neovim/pull/14681), and match the rest of the UI.
I also have another project I was working on before the 0.5 stabilization phase (https://github.com/mjlbach/neovim-ui). The goal with this is to have composable/overridable UI elements built into core (which we would use for our internal lsp functions), that can be used (or overridden) by UI plugins.
In summary, I think the likelihood of autocompletion (and generally auto-anything) being built-into core is very small, but providing the APIs in neovim core to make snippets - autocompletion - automated UI elements easier for plugin authors is a high priority.
The first transpiler to mention here would be https://fennel-lang.org/ and
Hi, I'm a maintainer. I think this is a huge mis-characterization of the team. We definitely are aware (and inform users) the current state using the theia wrapper lags coc.nvim and vscode. We've never said anything disparaging about coc.nvim, and the built-in client is still seeing rapid development.
We provide a client, not language servers, so we're kinda at the mercy of whatever language servers exist. We offer a configuration in lspconfig for https://github.com/theia-ide/typescript-language-server which wraps tsserver, but there is hope that microsoft could implement lsp protocol directly for tsserver https://github.com/microsoft/TypeScript/issues/39459#issueco... at which point the experience should be more comparable to coc.nvim.
On a different note, we have made upstream requests to MS, worked with language server authors, and generally try to contribute positively to the language server ecosystem. Neovim users will always be free to use coc.
If you have actionable items for improving the client, please reach out on our discourse or on our matrix channel. Thanks!
Hi, I'm a maintainer. I think this is a huge mis-characterization of the team. We definitely are aware (and inform users) the current state using the theia wrapper lags coc.nvim and vscode. We've never said anything disparaging about coc.nvim, and the built-in client is still seeing rapid development.
We provide a client, not language servers, so we're kinda at the mercy of whatever language servers exist. We offer a configuration in lspconfig for https://github.com/theia-ide/typescript-language-server which wraps tsserver, but there is hope that microsoft could implement lsp protocol directly for tsserver https://github.com/microsoft/TypeScript/issues/39459#issueco... at which point the experience should be more comparable to coc.nvim.
On a different note, we have made upstream requests to MS, worked with language server authors, and generally try to contribute positively to the language server ecosystem. Neovim users will always be free to use coc.
If you have actionable items for improving the client, please reach out on our discourse or on our matrix channel. Thanks!
Tree-sitter based text-objects are one of my favourite parts of neovim 0.5 too. Now I can have class, function, parameter, and comment text-objects that can be manipulated as easily as words or paragraphs.
This plugin sets it all up and has some examples: https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
Tree-sitter based text-objects are one of my favourite parts of neovim 0.5 too. Now I can have class, function, parameter, and comment text-objects that can be manipulated as easily as words or paragraphs.
This plugin sets it all up and has some examples: https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
which-key.nvim too, plus more features. Really useful for remembering/learning new plugin mappings.
https://github.com/folke/which-key.nvim
Embrace, extend, extinguish
They've done it before and they'll do it again.
LSP for MS and VS Code is "come, make our proprietary editor more valuable by supporting languages we can't be arsed to worry about!"
https://github.com/microsoft/pylance-release/issues/4
(I am an enthusiastic advocate for LSP otherwise.)