Live data from Hacker News

Neovim 0.5 is overpowering

crispgm.com

301–310 of 429 posts

Re: Neovim 0.5 is overpowering

#301
post #286
post #212

I'm in the curiously rare position of being a long time Neo/vim user who doesn't use its modal features. Namely I have all my keybindings setup like a "normal" editor, CTRL+S to save etc. I say it's curious because I've always been surprised that Neo/vim is mainly celebrated as "that modal editor". Whereas for me I celebrate it as the most feature-packed and lightweight terminal editor. Neo/vim is sooo much more than…

How very, very naughty! Delightful, but not for me, thankyouverymuch! I'm curious about why, though? What parts of vi(m) do you get to keep that this makes sense for you?

I always thought it was obvious that Vim has one of the best, if not the best ecosystem, plugins, documentation, community. And its portable. I absolutely love Vim for so many reasons, normal mode is just not one of those reasons.

Re: Neovim 0.5 is overpowering

#302
post #237

Does neovim, or vim for that matter, offer any out of the box support for remote work like Emacs has with tramp-mode? Asking because maybe it's time to try NeoVim out, but it'd be a limitation for my work if I had to go through extra hops for editing remote files and running remote jupyter kernels. I suppose it does, so I'd be grateful if vimmers out there would share their favorite solutions.

Netrw, as a sibling comment mentions, does this for a number of common protocols (and is built-in). So you just open an file with a URL starting with sftp or whatever.

https://www.vim.org/scripts/script.php?script_id=1075

Re: Neovim 0.5 is overpowering

#303
I've been a using vim for well over a decade. I switched over to neovim for the native LSP support. I spend most of my time programming in neovim but I also have goland installed which I use for high level refactorings such as "extract method" or "change signature". Once I can do these high level refactors with nvim+gopls then I can finally leave goland.

Can't say I really care about more syntax highlighting or lua. Less config is better.

Re: Neovim 0.5 is overpowering

#304

I'm most excited for the treesitter integration and its potential to amplify Vim's "killer feature": text editing as a language. Vim's editing language feels most powerful when I'm using its text objects: "ciw" means "change in word", "cis" means "change in sentence", and so on. But Vim's built-in text objects are not always a perfect match for the code you're editing. Suppose you want to change the first argument of…

Aren't these features are subject to external configuration to behave properly? For example, C/C++ and #defines. The user has to configure yet another file for this to work properly. If the build system/tree is so complicated that I can't figure out what the final #defs are (like building MBED programs with literally a thousand #defs), I end up shutting off this feature entirely. This kills me with VSCode & Sublime,…

You make your build system emit a compile-definitions.json file that has all the compiler flags for every file you compile and feed it to a language server (rtags or clangd usually, either standalone or part of another plugin like YouCompleteMe). CMake has a flag to do that as part of its configuration step (and remembers it), for other build systems you can use something like bear: https://github.com/rizsotto/Bear .

Re: Neovim 0.5 is overpowering

#305

I'm a long time (20+ years) vim user, and neovim doesn't fit my use case. I've tried it, most recently today, to have a look at LSP and treesitter. Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree. LSP and other "make it into an IDE" I usually turn off after a few minutes, it's more of a hindrance than a help. I mainly co…

Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1].

The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.

[1] https://www.youtube.com/watch?v=pW-SOdj4Kkk&t=2546s

Re: Neovim 0.5 is overpowering

#306

Earlier quoted context omitted.

I’m pretty sure that the primary reason we don’t have more VIM plugins, despite many more emacs users, is vimscript being terrible. If vim had a more usable scripting language it would have easily surpassed emacs in plugins and more importantly, since plugins would have been more popular, vim would have been developed in a way to make it more extensible and nvim wouldn’t even be needed.

The philosophy of vim is to be able to do a lot without the need for complex plugins, as opposed to emacs' world view. That's why vim script is good only for simple scripting tasks. I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself. After all, emacs lisp is not the best language in the world and only a small group really knows it beyond the basics.

> emacs lisp is not the best language in the world

Emacs-lisp is a Lisp. It may not be the best of Lisps, but even a bad Lisp can be far more powerful than many other non-lispy languages. To understand what makes Emacs so awesome, one has to understand the philosophy of Lisp. Emacs Lisp is not just a text editor, IDE, email client, project management tool, scientific calculator, etc.

Emacs, first and foremost is a Lisp environment. Definitely not the most ideal, but certainly the best one we have today.

> I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself

I believe, Emacs held the crown of "the most malleable" tool for over forty years, specifically because it builds on top of Lisp.

Number of plugins is not an indicator. They also have to "play nicely" with each other. I just checked - I pull over four hundred Emacs packages in my config, including built-ins and dependency libs. I just cannot imagine any other IDE or text editor with 400 plugins installed. That's just not possible.

Re: Neovim 0.5 is overpowering

#307
post #275
post #52

Earlier quoted context omitted.

Vimscript is terrible though. I switched from Emacs to Vim (and later, neovim) last year and the shock of going from elisp to vimscript was intense. I even contributed some small patches to a couple of vim plugins which meant writing and debugging vimscript, I hated every second of it. I'm not a huge fan of Lua either mind you, but I'll take it any day of the week over vimscript.

I've always wanted to write Vim plugins, and as soon as 0.5 hits stable, I'm looking forward to trying! I won't touch VimScript with a 10-foot pole, and I write code for a living. It's not worth my time, and it does not commute to other things that I'd rather be spending my time coding.

But you can use Python to write Vim and NeoVim plugins already. It's arguably an even better language than Lua.

Re: Neovim 0.5 is overpowering

#308
post #52
post #15

I use nvim in the terminal and gvim/macvim on the desktop. I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins (vimscript plugins are better because they work with both vim and neovim). Switching to init.lua also means losing all compatibility with vim, and I cannot fathom why people would want to do that considering that there is nothing that init.vim cann…

Vimscript is terrible though. I switched from Emacs to Vim (and later, neovim) last year and the shock of going from elisp to vimscript was intense. I even contributed some small patches to a couple of vim plugins which meant writing and debugging vimscript, I hated every second of it. I'm not a huge fan of Lua either mind you, but I'll take it any day of the week over vimscript.

> I'm not a huge fan of Lua either mind you

If you liked emacs-lisp, perhaps you should try Fennel. It's a tiny Lisp that compiles to Lua with zero overhead.

It's pretty dope.

Re: Neovim 0.5 is overpowering

#309

Earlier quoted context omitted.

The way vim works is actually the opposite of what your brain wants, this is one of the reasons why learning vim tricks is hard. The vim model is "action-object" (eg dw, delete word). A more natural, friendly and interactive model is the opposite, "object-action": first you select the text, your editor highlights the text, then you apply actions to the selection, one by one, and see what happens after each one. Becau…

You've oddly crystallized why Kakoune has so far failed to grab me! The description you gave of the actions one takes in editing makes sense: in most non-modal editors, you select the text you want to take actions on, then choose the action to take. But, I can do that in literally every modeless editor! That's the way essentially all of them work. But when people write of "Vim as a text editing language" as many comm…

It is pretty common nowadays in functional programming languages to find operators which reverse the order of application or composition, so rather than writing f(g(h(x))) one can instead write “x |> h |> g |> f”. This style is quite popular, which leads me to believe that many people prefer object-action over action-object in same way. (Although perhaps this is more a critique of action-object-object vs object-action-action)

Re: Neovim 0.5 is overpowering

#310

Earlier quoted context omitted.

The philosophy of vim is to be able to do a lot without the need for complex plugins, as opposed to emacs' world view. That's why vim script is good only for simple scripting tasks. I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself. After all, emacs lisp is not the best language in the world and only a small group really knows it beyond the basics.

> emacs lisp is not the best language in the world Emacs-lisp is a Lisp. It may not be the best of Lisps, but even a bad Lisp can be far more powerful than many other non-lispy languages. To understand what makes Emacs so awesome, one has to understand the philosophy of Lisp. Emacs Lisp is not just a text editor, IDE, email client, project management tool, scientific calculator, etc. Emacs, first and foremost is a Li…

Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs. It is the other way around: it was Emacs that created Emacs lisp. Initially, emacs was created on top of TECO, arguably the worst, most difficult programmable editor ever created. TECO language was so bad that they decided to switch. But emacs, the editor, was successful even running on top of a terrible language that nobody liked at the time.
Post reply on HN