Live data from Hacker News

Neovim 0.7 Released

github.com

131–140 of 220 posts

Re: Neovim 0.7 Released

#131

Earlier quoted context omitted.

If you have ever said the word "bloat" unironically on your computer with 64G of RAM, built in might be for you. I really just want one config that works on: * Yes, my Ryzen 5 with 32G of RAM * My Pinebook Pro with 4G of RAM (and like 3.7G accessible) (and limited storage as well) * My jump host / gateway VM with 512MB of RAM (and even more limited storage than the PBP) So pulling down and running node.js to use coc.…

A lot of LSPs are written for node though, like pyright for example (yes, the best python LSP is written in typescript). It's kind of unavoidable to use node at some point if you're using LSPs in your editor.

> It's kind of unavoidable to use node

This. Learned it the hard way. For many moons, I tried integrating YouCompleteMe and the like. Then one day, I just gave up and switched to `coc.nvim`

Re: Neovim 0.7 Released

#132

Neovim is such a weird derivative utility to me. Derivative/forked software usually isn't very successful to begin with, but then Neovim makes attempts to be modern and it's so not appealing at all. Here are some 5 second examples. Example 1: nvim . Still uses Netrw, which is fine, but doesn't even attempt to do things like: let g:netrw_preview=1 let g:netrw_banner=0 let g:netrw_browse_split=4 let g:netrw_liststyle=…

You might reconsider your expectations. Neovim is not trying to occupy the same space as something like VSCode or Atom. Its focus is on being extremely extensible without sacrificing performance - just look at the website, it's right at the top of the feature list.

The intention is for it to serve as the core technology for any number of vi-like text editing setups. It's not batteries-included, but there are batteries everywhere if you look.

    Mouse is off by default. Again, why? I get that it's a terminal editor, but if the technology is there to allow me to select text with my mouse, why do we need act like luddites?
Because it would be unexpected and unwelcome behavior for most users, and maybe even introduce undefined behavior in clients that lack mouse support.

    After setting up my .vimrc file with sane defaults and a bit of an attempt to use the editor in earnest, my conclusion is that Vim/Neovim is just a bad editor.
You haven't really explained why you think it's a bad editor, beyond the default settings you don't like.

Re: Neovim 0.7 Released

#133
post #101

People who have tried both vim and nvim: - I have a theory that using `coc.nvim` is still the superior solution even compared to a native LSP. Why? Cause we can siphon from the huge man-hours of development and polish that M$ has put on VSCode. Every time they tweak VSCode, we at downstream, enjoy the benefits. Am I wrong in my assessment? - Vim's regexp-based syntax highlighting is annoying. So I think nvim+tree-sit…

I came from coc.nvim and switched to the native LSP when it was released on nightly. For a while I was using VSCode and came back to nvim and switched back to coc.nvim. I found that the native LSP's community to be too quickly changing. Plugins that were necessary earlier weren't, while new necessary plugins came into play. But, coc.nvim was steady chugging along and my old settings file worked out of the box. I'm al…

Same for me, coc.nvim community is rock solid whereas native LSP requires more configuration and is much less reliable version-to-version

Re: Neovim 0.7 Released

#134

I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging…

Integration. The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth. Vscode or Jetbrains or any other integrated software is from the ground built up to have its tools work together 100% of the time. I like vim fine if I edit something without any plugins needed but otherwise I'll stick with an IDE. And i…

> The last time I tried neovim the LSP kept crashing for me on random occasions, some plugins had considerable performance issues, some things weren't async, and so forth.

Any issues with the language server I doubt are client side, and every request/response is "async".

For a minimum setup it is:

1. Install the language server via opam:

  opam pin add ocaml-lsp-server https://github.com/ocaml/ocaml-lsp.git

  opam install ocaml-lsp-server
2. Add lspconfig, the plugin

3. Add the following to your init.lua

  require'lspconfig'.ocamllsp.setup{}
4. That will give you basic linting, you can add keybindings/omnifunc integrations by copying out our configuration examples from `:help lspconfig` or the lspconfig wiki.

We're not trying to target vscode users, so if the above is too many steps that is ok, you just aren't our target audience.

Re: Neovim 0.7 Released

#135
post #54

I think Helix does a lot right on the "initial configuration" front. It comes with LSP and treesitter configured out of the box. Neovim on the other hand is heavily customizable, but you also have to do this for awesome functionality

I switched from Kakoune to Helix recently. I've been very happy. It'll be a larger leap for a Vim user, but it was almost drop-in for a Kakoune user. Though i did tweak my bindings quite a bit to be more Kakoune like hah.

What kinds of improvements does Helix offer over Kakoune?

Re: Neovim 0.7 Released

#136

Earlier quoted context omitted.

I could ask the opposite: why do people choose terminal vim when you can easily add nvim integration to editors like VSCode and get 98-100% of what vim gives you along with much easier configuration of all those extras you mention like autocomplete, hover reference, refactor, etc.? That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a f…

The 100% full reason for me was that I had a job where I needed to SSH into our prod server about once per month and tweak some files. I was so terrified every time I had to do it because I was afraid of vim and/or nano in those situations. So I decided to get competent so I trusted myself not to make huge mistakes. After about a week of using vim it clicked and I knew I couldn't go back to Sublime Text. As for VS Co…

> The 100% full reason for me was that I had a job where I needed to SSH into our prod server

Statements like this are common, but they confuse two usages: (a) learning vi/vim well enough in order to use it in any unix environment vs. (b) using vim with a complete plugin/config suite as a primary development IDE replacement tool.

The former is IMHO an essential unix skill, but it's incredibly inefficient to try to use core out-of-the-box zero-plugin vim as a primary development tool. But once you start configuring an efficient dev environment, the GUI editors start to really outshine vim, and they still provide core vim functionality via plugins if you want it.

Re: Neovim 0.7 Released

#137

I will never understand why people choose VSCode/Jetbrains over a terminal based editor. I can edit the kernel with clangd and get hover reference, autocomplete, go to def, ref, dec, smart refactor, and that's on top of being able to easily jump and fix lint/bugs using Vim's already great support for parsing compiler errors. With term added (which is a core Vim feature) it also has excellent support for gdb debugging…

I don't know why people would use a text editor in a terminal when they can use that same text editor as a desktop application.

Fonts are better, colors are better, it is faster, less latency, running a terminal inside your editor works better, pop-ups and overlays work better/are more flexible/easier to read, mouse interactions work better, resizing works better, it is easier to run multiple windows, it is easy to run multiple different fonts with different font sizes, etc etc.

I also don't have to figure out solutions to conflicts between the keyboard shortcuts between the shell, the terminal, the terminal multiplexer (screen/tmux/tabbed terminal emulator), and the editor.

> I can use my editor over ssh and edit anywhere

I can just have my editor use ssh to edit files anywhere. Remote editing is a thing.

Anyways for proper system hygiene you shouldn't be shelling into anything except to troubleshoot problems or for checking things you don't have monitors in place for. This is why we have things like ansible or puppet.

In fact the whole insisting on having an editor in a terminal emulator thing is probably holding Nvim back as a whole. Which is why you don't see the obvious benefits.

Since the community wants to use terminal emulators so heavily then all the add-ons and features of the editor must support the lowest common dominator between desktop apps and terminal emulator, which is almost always going to be the terminal emulator.

Just remember that you are not avoiding a GUI by using a terminal emulator. It's still a GUI. Just a GUI designed for running command line applications in a Unix-style shell. And Neovim really isn't even a command line application.

Re: Neovim 0.7 Released

#138

I did a brief write up on some of the biggest new features here: https://gpanders.com/blog/whats-new-in-neovim-0-7/

> One use case for the new remote functionality is the ability to open files from the embedded terminal emulator in the primary Neovim instance, rather than creating an embedded Neovim instance running inside Neovim itself.

Hmm, if I type "git commit" within the terminal, is there some value of $EDITOR that would make it launch a buffer to edit the commit message, then finish when I close the buffer? (and if so, are there distinguishable success vs failure ways to close the buffer?) That's my biggest editor-within-an-editor moment.

Re: Neovim 0.7 Released

#139
post #83

Earlier quoted context omitted.

I could ask the opposite: why do people choose terminal vim when you can easily add nvim integration to editors like VSCode and get 98-100% of what vim gives you along with much easier configuration of all those extras you mention like autocomplete, hover reference, refactor, etc.? That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a f…

I find Coc.nvim plugins for neovim are virtually just as easy to set up as VS code plugins, VS code is a power hog and performs worse, and the vim bindings are rough around the edges with macros in particular. VS Code with a vim plugin is not a bad experience, but neovim+coc.nvim is just much snappier.

That may be, but this is the first time I've heard of coc.nvim and I've used neovim for years. So I'll bookmark this and at some point I'll look into it and do some research and figure out how to configure it and compare it to competitors, but is all that really worth the very slight performance advantages we're talking about? I can't type 1000wpm after all.

Sure, VSCode is a power hog and it's slow, but I make pretty good money so the cost of a more powerful development machine is trivial compared to the opportunity cost of doing all that research. Some years I really enjoy learning all about new ways to configure vim/nvim, but I recognize that it's really not an efficient use of my time, it's just been something I do more for fun.

Re: Neovim 0.7 Released

#140

Earlier quoted context omitted.

I switched from Kakoune to Helix recently. I've been very happy. It'll be a larger leap for a Vim user, but it was almost drop-in for a Kakoune user. Though i did tweak my bindings quite a bit to be more Kakoune like hah.

What kinds of improvements does Helix offer over Kakoune?

For me it was that it worked mostly just like Kakoune (or at least, the parts i used of Kakoune) with nicely integrated LSP. It also had TreeSitter based movement options and themes, which is really interesting too. A potential future where vim-like navigation is done on TreeSitter objects is attractive.

The potential DSP integration is nice too. And to top it all off, it's made in a language i enjoy and within the first 24h of using it i had a PR made for a small feature i wanted. Being able to contribute in a language i enjoy was nice.

Post reply on HN