Live data from Hacker News

Neovim v0.5

github.com

161–170 of 213 posts

Re: Neovim v0.5

#161
I have been waiting for 0.5 for ages. While most of us are trying to justify one text editor over the other, I am using combination of them depending upon the usecases. I use Neovim most of the time and use Vscode for special cases like getting previews on Markdown, PlantUML, and stuff.

Sure we can do same with Neovim, it's just I don't like memorizing every possible commands. It would be great to have a command that lists all the available commands in Neovim along with some description and fuzzy finding just like in VSCode and Sublime.

Re: Neovim v0.5

#162
post #102

Earlier quoted context omitted.

I'll give you my perspective (I'm just an average user): 1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled. 2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a l…

> Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal. This goes back to my biggest complaint with the vim ecosystem (and emacs has the same problem): no dependency management. Almost every plugin has to be self contained, because if you depend on another plugin, then you need to rely on you users to manually install that plugin.

Packer is a plug-in manager for neovim that uses packadd and has support for adding dependencies in the install step.

Re: Neovim v0.5

#163
post #87

Earlier quoted context omitted.

I am not sure how this is possible Editors like Vim, Emacs or VSCode are all about the plugins I use emacs for org mode And VSCode for everything else, because simply most proramming languages have their main plugins on VSCode The only way you can move from VSCode to neovim is, if you dont care about the plugins Why would you VSCode if not for the plugins

Regarding programming languages, the answer is the language server protocol (LSP), an editor-agnostic way to use IDE-like features, originally developed for VSCode. Works for both Neovim and VSCode (and many others). Somewhat ironic that one of VSCode's best inventions is the one which made me switch away from it.

I saw it as Microsoft's signalling that they care more about being in the good graces of the wider developer community than about dominating the programming editor/IDE market. After all VSCode is free. I'd argue that giving away VSCode, LSP, Monaco (the base editor) and so on has been a successful means of redeeming their brand in the eyes of developers and really anyone who ever touches code. That could backfire if they took on an aggressively competitive stance. Letting LSP play nicely with other editors seems therefore good business for them. It also appears that as a profitable business, money Microsoft spends on VSCode might otherwise be spent as taxes?

Re: Neovim v0.5

#164

Earlier quoted context omitted.

Wow, I’ve been a vim user for like 8+ years and didn’t know about 0p even though I run into that problem all the time. I had even re-bound yank/paste to use a different register. Thanks for the pointer! This is what I love about vim, there’s always something new to learn.

LunarVim has a "show b̶u̶f̶f̶e̶r̶s̶ registers" plugin enabled so when you type " it brings up a window showing the contents of various buffers, so you can eyeball it rather than remembering.

https://github.com/junegunn/vim-peekaboo

Re: Neovim v0.5

#165

Earlier quoted context omitted.

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.nvi…

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 conserv…

If we're just spitballing thoughts, I'd like something that's kind of the opposite of zen mode. I don't always want signatures and completions and things binging and bopping and showing me suggestions--if I'm working on a codebase and language I'm fluent in then all of that gets turned off. But if I have to pick up some under-documented massive codebase where everyone just uses VS code/intellisense--I'm going to need all the suggestions.

So IMHO I'd love effectively a dial, perhaps the 'distractions' dial. It's not a binary on/off, it's a spectrum. It could be off--nothing at all distracts me (zen mode basically). It might be on a little bit--perhaps just showing current stuff LSP does by default, errors, etc. And it might get cranked up to max--every keystroke throwing more information at me about what's happening, what am I editing, what's related to it, etc. During an editing session I might move inbetween each level on the distraction dial many times. Kind of like zooming in and out as you're editing a photo.

Re: Neovim v0.5

#166
post #119

In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS…

Agreed. It took me half a day and I came not remotely to the UX and performance of coc.vim. Most incl. the nvim team are not aware that eg. tsserver is the fastest and most responsive code formatter for TS (yes, it goes beyond the LSP spec but that's how it is, also for historical reasons). Prettier does not come close.

Maybe they've never tried or deliberately ignore coc.vim for whatever reason. coc.vim works almost out of the box, has the fastest and most pragmatic maintainer who helps anyone and tsserver makes it as good and as fast as VS Code. Instead of just cloning coc.vim's tsserver implementation—or why do they no contribute to coc.vim??—roll their own inferior solution, years later. It's not that nvim's LSP implementation is at its beginning and we can expect more is coming, no the maintainers just do not know or ignore the status quo. Feels very much like Bram a decade ago.

Maybe it's time that we see a third fork—coc.vim.

Re: Neovim v0.5

#167
I'd love to love neovim, but is seems there's not a easy way to install a "self contained subset". For some langs it misses some "OS" dependencies, resulting in sluggishness and annoying errors all over the place, when I just want to open a file from the terminal or in a non-IDE.

If someone knows a way to install a version of neovim that does not need OS deps...

Re: Neovim v0.5

#168
post #102

Earlier quoted context omitted.

I'll give you my perspective (I'm just an average user): 1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled. 2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a l…

> Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal. This goes back to my biggest complaint with the vim ecosystem (and emacs has the same problem): no dependency management. Almost every plugin has to be self contained, because if you depend on another plugin, then you need to rely on you users to manually install that plugin.

Emacs nowadays have package management. And doom emacs is even better in that, because the management is declarative (you have a file with all your packages and it installs them and their dependencies)

Re: Neovim v0.5

#169
post #62

Earlier quoted context omitted.

I’d say cautiously maybe. Using lua to me seems like it could open doors for neovim that before we’re either not possible or very complicated to do with vimscript. Neovim doesn’t have such incredible and almost ridiculous power to change itself like emacs does with elisp since vim is still not written in lua, lua is just used to access its api, but that api is quite extensive. So, maybe? Hopefully?

And if you really want Lisp in Neovim, you can use the Aniseed framework to write your plugins and scripts in Fennel.

Thanks for pointing out Fennel! every since I learned a little of elisp I really enjoyed the experience but common lisp seems like a beast to big to take on, clojure run on java and tbh I'm prejudiced against it... but fennel is just a simple lisp that runs on lua with no overhead? now that's something I can get behind!

Re: Neovim v0.5

#170

I have been waiting for 0.5 for ages. While most of us are trying to justify one text editor over the other, I am using combination of them depending upon the usecases. I use Neovim most of the time and use Vscode for special cases like getting previews on Markdown, PlantUML, and stuff. Sure we can do same with Neovim, it's just I don't like memorizing every possible commands. It would be great to have a command that…

> It would be great to have a command that lists all the available commands in Neovim

Both the fzf.vim and telescope.nvim plugins provide a fuzzy searchable list of commands; `:Commands` and `:Telescope commands` respectively. The built-in commands have a description but commands from plugins usually just show it's definition.

Post reply on HN