Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neovim v0.5

github.com

Post reply on HN
Print view View original

181–190 of 213 posts

Re: Neovim v0.5

#181

Post by marcthe12 »

celeritascelery wrote: post #130
ibraheemdev wrote: post #114

One little-talked about advantage of Lua support is that you can now write your vim config/scripts in one of the various Lua transpilers like moonscript [0], or maybe even typescript [1]! [0]: https://github.com/leafo/moonscript [1]: https://github.com/TypeScriptToLua/TypeScriptToLua [2]: https://github.com/hengestone/lua-languages

I am curious if there are any major packages written in lua for neovim? I wonder if ecosystem fragmentation will become an issue (vimscript vs Lua).

It will as regular vim is doing vim9script. So it will be legacy vimscript vs lua vs vim9scrpt.

Re: Neovim v0.5

#182

Post by b3n »

e12e wrote: post #148
Tehchops wrote: post #138

Earlier quoted context omitted.

> VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. I'm surprised to hear this take. I've been a Doom Emacs user for a while, and while it was a bit more elbow grease to get it running on OSX, it was generally worth it for the speed/flexibility... until I ran into a non-trivially large Terraf…

FYI the few times I've half-earnestly tried emacs+evil one of the reasons I've gone back to (neo)Vim is that emacs feels sluggish. I'm sure at least one time spacemacs was partly to blame (aka ALL THE THINGS activated/installed) - but it's definitely a difference in "feel" where (Neo)Vim feels closer to vi, and emacs feel closer to vs code/Atom.

Have you tried vanilla Emacs without any plugins (aka `emacs -Q`)? It's blazingly fast for me.

Re: Neovim v0.5

#183

Post by malloryerik »

draebek wrote: post #180
malloryerik wrote: post #163

Earlier quoted context omitted.

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…

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.)

> Embrace, extend, extinguish. They've done it before and they'll do it again.

Truly a valid concern.

Re: Neovim v0.5

#184

Post by reader_mode »

davidkunz wrote: post #98
systems wrote: 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.

If I am up to date TypeScript doesn't actually provide LSP and the 3rd party implementation is a wrapper around TS language server custom protocol and is worse in comparison. (They have/had plans to change this but it's been years since I saw the issue raised and not much progress from what I saw, haven't checked in last couple of months since I'm no longer in TS space)

IMO TypeScript is VSCode strongest use case - I would use VS code over VisualStudio for example on C# projects when I had to edit fronted parts - it was so much better. IntelliJ TS stuff is the only thing that comes close/is on par maybe and I'm a happy camper in that ecosystem for the last few years.

None of the LSP plugins I've tried with neovim worked nearly as well as they do in VSCode (the few times I tried to spin it up for old times sake).

Re: Neovim v0.5

#185

Post by selectnull »

mmgutz wrote: post #145
linsomniac wrote: post #86

Earlier quoted context omitted.

I'm interested in what modifications you have made. I've been trying LunarVim a bit for the last week and am on the fence about going back to SpaceVim or just bare neovim. Not sure, still evaluating...

I want to like LunarVim but the everything-lua is a bit overboard. Compare this ` vim.api.nvim_set_keymap('n', ' ', ':bprevious ', {noremap = true, silent = true})` to `nnoremap :bprevious ` Why convert every single line of vimscript to a noisier lua statement? The Packer manager seems a step back from vim-plug. Your configuration file is no longer the source of truth. Packer uses a global site directory for plugin a…

I have just started to play with neovim and the first thing I did was to define a function:

  function bindKey(mode, keys, command, options)
    options = options or {noremap = true, silent = true}
    return vim.api.nvim_set_keymap(mode, keys, command, options)
  end
With that, remapping looks like this:

  bindKey('n', '', ':bnext')
Which is in my opinion better than Vim syntax. I definitely see the potential in having Lua as scripting language.

Re: Neovim v0.5

#186

Post by [deleted] »

flatiron wrote: post #136
systems wrote: 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

I don’t use any plugins with vs code. Am I the baddie? At least for JavaScript node crap it works perfect out of the box.

[deleted]

Re: Neovim v0.5

#187

Post by arp242 »

humility wrote: post #29
luke2m wrote: post #21

Could someone sell me on why I should switch to this from regular Vim?

lots of stuff. but mainly: * ease of getting started. nvim is just vim, you can bring over your vim config and it'll just work. * integrated lsp. you could have vscode like auto completion natively * tree-sitter. google it to believe it and much, much more

> you can bring over your vim config and it'll just work.

Except when it doesn't:

  $ nvim init.vim
  Error detected while processing /home/martin/.config/nvim/init.vim:
  line   44:
  E474: Invalid argument: completeopt=menuone,popuphidden,noselect
  line   50:
  E518: Unknown option: completepopup=highlight:Pmenu,border:off
  E824: Incompatible undo file: /home/martin/.cache/vim/undo/%home%martin%.config%nvim%init.vim
Or when opening a Go file:

  $ nvim a.go
  Error detected while processing function edc#init[34]..66_apply[40]..66_save:
  line    8:
  E121: Undefined variable: v:none
  E116: Invalid arguments for function get
  E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
  Error detected while processing function edc#init[34]..66_apply[32]..66_save:
  line    8:
  E121: Undefined variable: v:none
  E116: Invalid arguments for function get
  E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
  Error detected while processing function edc#init[34]..66_apply[2]..66_save:
  line    8:
  E121: Undefined variable: v:none
  E116: Invalid arguments for function get
  E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
  Error detected while processing function edc#init[34]..66_apply[14]..66_save:
  line    8:
  E121: Undefined variable: v:none
  E116: Invalid arguments for function get
  E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
  Error detected while processing function gopher#go#set_build_package[11]..gopher#go#module:
  line   12:
  E117: Unknown function: chdir
And they don't even always show properly on startup (just "press ENTER", need to use :messages).

There's loads of incompatibilities; some behaviour is different as well. I can't get it to stop clearing the terminal on exit for example; my 'nnoremap p "*p' mapping just inserts '"', my Control+space mapping doesn't work for whatever reason, for some reason a lot of stuff looks different even though it has the same colour scheme, quite a number of my custom functions/commands/mappings error out for various reasons, etc. etc. And not all of these are very complex either: is a simple expression map: inoremap pumvisible() ? "\" : "\\" – Pressing works, but this doesn't(?)

"You can bring over your vim config and it'll just work" might be true is you have a simple vimrc with a few basic ":set"s, but it breaks down very fast.

Re: Neovim v0.5

#188

Post by arp242 »

kellyjprice wrote: post #116
njharman wrote: post #113

Earlier quoted context omitted.

My vim config includes bunch of customization for bunch of plugins written in vimscript. Will that just work?

Probably. I have not had any problems switching between the two. It's meant to be a drop in replacement, but I'm not sure how perfect that is.

Compatibility was a goal at the start, but now it seems to be on a "best effort" basis at best. It's very much non-perfect because opening anything in neovim with my Vim config gives me a forest of errors and loads of things don't work, including some pretty basic stuff like expression mappings. See my other comment in this thread as well.

Re: Neovim v0.5

#189

Post by arp242 »

gorjusborg wrote: post #66
luke2m wrote: post #21

Could someone sell me on why I should switch to this from regular Vim?

To me, there are two big things: 1. Development model (vim=Bram, neovim=communitiy of people) 2. Movement to a more accessible language for writing plugins

It's true that "all patches go through Bram", but Vim has other maintainers as well and there's loads of people working on it. I had several patches merged with feedback from several non-Bram maintainers, with faster than average turnaround times I might add (i.e. several days or less before it ended up merged in Vim).

Re: Neovim v0.5

#190

Post by arp242 »

rektide wrote: post #8

Bundling in a bunch of plugins[1] feels semi-cheating for shipping a new release, but I'm ok with it. I do get a bit of a monolithization vibe, and it kind of scares me to think that neovim might get stuck with some ever-ossifying codebases it shouldn't have pulled in, but overall I think the gains of building a more rich, integrated, baseline editing environment probably justifies the damage of consolidation/picking…

> Bundling in a bunch of plugins[1] feels semi-cheating for shipping a new release

Vim has been bundling plugins since forever. Netrw, for example, is just a bundled plugin, but also a bunch of others like matchit.

This is an implementation detail IMO. Firefox also implements some of its functionality via extensions: screenshots, picture-in-picture, and various web compat hacks are all extensions. Most people don't even know and couldn't care less.

Post reply on HN