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

LazyVim

lazyvim.org

Post reply on HN
Print view View original

411–420 of 537 posts

Re: LazyVim

#411

Post by cempaka »

pkulak wrote: post #100
silasdavis wrote: post #89

Earlier quoted context omitted.

I can identify with much of this. After an unfortunate bout of Java development, I was flung into the arms of Intellij, steadily won over by the indexing and the reliability of the refactoring tools. The Vim plugin was good enough and defining some chords for editor shortcuts resulted in a kind of fucked up fat vim emacs mode that was quite productive. I, too, got fed up of spending inordinate amounts of debugging vi…

Don’t even bother using anything but IntelliJ for JVM work. I use Neovim for everything, but not Java/Kotlin.

I spent quite a long time trying to get nvim-jdtls configured correctly and playing well with all the other LSPs I have configured. Had it mostly working and I did like writing a large amount of Java for a greenfield project in Neovim, but then a bunch of it broke again when I upgraded either nvim or one of its plugins. So I spent some time trying to make the IdeaVim plugin work as closely as I can get it to my Neovim setup and am finding that to be a happy medium. But I might still come back to Neovim for raw editing at some point if the LSP issues do get sorted out.

Re: LazyVim

#412

Post by _mis1 »

CiTyBear wrote: post #179

Many people complain about the time you need to have a proper vim. In computer security, I learnt to make my own tools, to develop my own script that match what I want to do/scan. For vim, this is exactly the same. I started with Python so my vim became the best Python IDE (for me) and that's all. What I said to junior dev is "Here my vim conf, you are allowed to copy/paste only what you understand". Then I did some…

> Everytime I test vscode, it does not do what I want and when I look into it, I can't configure it correctly. Vim has always my back.

Can you expand on this? What specifically does not work for you on vscode?

Re: LazyVim

#413

Post by DiabloD3 »

gsinclair wrote: post #344
majjam wrote: post #266

Earlier quoted context omitted.

Would you mind sharing it? Im just getting to grips with vim so any pointers towards some simple improvements would be much appreciated.

Take a look at the vim-sensible plugin. No need to install it, just see what the generally agreed sensible settings are.

Most of vim-sensible is already default or equivalent on Neovim, fwiw.

Re: LazyVim

#414

Post by moistoreos »

The mnemonic bindings I get from my config are an integral part of my workflow and super easy to add/update/change. But the primary reason for using Neovim is I don't have to leave the terminal. I switched entirely to the CLI a few years ago and I am more productive here.

If I wanted an IDE, I'd switch to the terminal version of Emacs.

Re: LazyVim

#415

Post by serial_dev »

constantcrying wrote: post #347
serial_dev wrote: post #138

Earlier quoted context omitted.

Sure, it's one hour if you did that already 20 times and you know the ecosystem. An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing). If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, findin…

I am not talking about learning vim. Of course, that is a huge time investment and you have to make your own judgement if that is worth it (for me it absolutely was, but I was in University with few obligations and lots of time). I am talking purely about going from a vim without IDE-like tooling to one including it. That can be done in an hour.

Still, IMO it can only be done in an hour if you've done it already... You need more time than that for finding the plugin candidates, evaluating them, installing the right plugins, then you need a test run where you lookup the key bindings, on vim it's not as easy to discover features as in a "GUI" IDE.

Re: LazyVim

#416

Post by masukomi »

altonas wrote: post #271
majkinetor wrote: post #265

Earlier quoted context omitted.

Then you musta accept suboptimal UX. Its one way to live your life.

Can you actually explain how it's suboptimal UX, and what I could be doing better. I want a simple IDE, not suboptimal bloat. I don't need 200 keybinds to make a vue component. Just because you have a bunch of custom quirks doesn't mean that I do.

The thing about vim and emacs is that both of them, out of the box, suck. BUT, what they both offer better than anything else, is the ability to gradually modify them to match what your brain needs.

I 100% agree with your hyperbolic "200 keybinds to make a view component" But that's ...that's not how it works unless that's what your brain wants.

With ALL editors you eventually encounter "ugh, this is frustrating" or "i wish i didn't have to do that" and then you have 30+ years of plugins and configs you can draw on to modify it to match your liking without any coding. VERY rarely, you'll want to tweak it in a way that there isn't a plugin / config for and you'll find communities of very helpful people who'll respond with "what about this solution..."

The fact is that _your_ brain is different from everyone else's. The less configurable an editor is the less it will be able to support the way your brain likes to work.

You _can_ accept pre-made defaults like those provided by VSCode OR you can gradually refine your editor to be a perfectly crafted tool for your particular and very individual way of thinking.

I choose the latter because i spend SO much time staring at my editor and trying to convince it to do things that are almost always better with automated assistance from it.

Re: LazyVim

#417

Post by turboponyy »

oblio wrote: post #387
turboponyy wrote: post #345

Earlier quoted context omitted.

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the…

> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds. I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only h…

This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.

The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.

Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.

For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.

Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.

The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.

Re: LazyVim

#418

Post by w0m »

adamkf wrote: post #42
w0m wrote: post #21

Earlier quoted context omitted.

copilot works wonderfully inside NeoVim; I use it daily. You are right that some of the more advanced integrations (Chat, direct analysis/explanation) aren't ported though. I use shellgpt in tmux for a (not as good but almost) experience.

I gave it a try the other day using copilot.lua, and it made the whole editor unusably slow. It somehow caused syntax highlighting to "lag" for tens of seconds every time I made any sort of edit. Maybe I need to be using the official plugin, and maybe I need to disable LSP based syntax highlighting, but that makes me wonder what it's doing.

I have pyright/shell running happily with lsbconfig and haven't noticed any lag. There's a way to profile plugins to see what's killing you I think.

Re: LazyVim

#419

Post by adamkf »

maleldil wrote: post #59
adamkf wrote: post #42

Earlier quoted context omitted.

I gave it a try the other day using copilot.lua, and it made the whole editor unusably slow. It somehow caused syntax highlighting to "lag" for tens of seconds every time I made any sort of edit. Maybe I need to be using the official plugin, and maybe I need to disable LSP based syntax highlighting, but that makes me wonder what it's doing.

What languages and LSPs are you using? I've never experienced this with Python (pyright), Go (gopls) or Rust (rust-analyzer). I'm using tree-sitter for syntax highlighting. The only special thing is that I'm using lazy.nvim (the plugin manager) to load copilot.lua on the InsertEnter event.

I am using typescript with typescript-language-server. I'll give the lazy stuff a try, but I am not sure why this would make the editor more responsive outside of the initial load.

Re: LazyVim

#420

Post by _V_ »

I was using neovim but nowdays I just fire up Sublime. neovim remains as a choice when I jump to other servers with SSH.

The thing is that when I'm (for example) trying to RE some protocol and have bytes-only view, I move things around quite a lot. And Sublime has a powerfull tool for this: multiple cursors. I can create as many cursors as I need and edit multuple instances/bytes at once.

Post reply on HN