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

Vim After 15 Years (2017)

blog.langworth.com

Post reply on HN
Print view View original

71–80 of 116 posts

Re: Vim After 15 Years (2017)

#71

Post by asciimov »

Trufa wrote: post #9

It's alway pretty fascinating to me that people can actually be productive without an IDE. I've tried several times Vim and I just don't get it how you can live without certain functionalities, I'm sure that with enough tinkering you can get pretty close but, for example, search seems to always be kind of a pain in the ass for the complex queries with regex through many files and stuff like that, specially the presen…

From my perspective, vim is just a tool that I picked up in college, back in the bad old days (early 00's) where good IDE's were paid and anything free was largely terrible.

Sure IDE's are great, I love stepping through code, it really helps when you're in deep and are having problems reasoning about the state of your program.

That said, every shop I've worked in used a different IDE. Possibly one picked out by some long gone coder who thought that their choice was the best.

Finally not being saddled to any one IDE lets me use the any other tool to get a job done.

Re: Vim After 15 Years (2017)

#72

Post by alwillis »

urthor wrote: post #66

Sadly, the Vim/Emacs configuration burden is growing every year. IDE developers just keep inventing new tools. GitHub Copilot is the latest, who knows what's next? Especially for Rust, JVM & Java. Rust without a IDE warnings is... extremely difficult. Unless you're extremely practiced with it. As time goes on, feature parity with fully featured IDEs like Jetbrains is steadily becoming harder. I'd readily consider a "…

Configuring Vim to catch-up with Intellij is becoming a part time job.

It doesn't have to be. I tried a bunch of things but LSP-Zero just works. The UI/UX for installing LSPs and linters, etc. is better than VS Code.

As time goes on, feature parity with fully featured IDEs like Jetbrains is steadily becoming harder.

As far as I can tell, there's no stated goal by anyone involved with Neovim to reach feature parity with any IDE. That's not the point.

What's great about Neovim and similar projects: there's a middle ground between a full-blown IDE and a "text-editor".

Just because a coder/developer wants some nice things like autocompletions, diagnostics, refactoring and semantic formatting and syntax highlighting doesn't necessarily mean they must use a IDE, especially when some of the underlying technologies for providing these features (Treesitter, Language Server Protocol) are exactly the same.

It won't take long for text editor users--Vim, Neovim, emacs, Hexlix--to expect these capabilities. It'll just become the norm. Just like how most young people today know a world without the internet being everywhere, we'll have users who've never known a time when every decent text editor didn't have what old-timers call "IDE" features.

Re: Vim After 15 Years (2017)

#73

Post by saurik »

lelandfe wrote: post #31
pmoriarty wrote: post #21

Earlier quoted context omitted.

I feel pretty much the opposite. IDE's seem incredibly limiting and feature-poor compared to editors like vim and emacs, which can do just about anything. Regarding your specific examples, both vim and emacs have file histories and if your files are under version control it's easy to get diffs. Searches are super powerful in both vim and emacs, and it's easy to search across multiple files as well using various scrip…

Worth noting that debuggers, which frequently have complex interfaces, are generally much better suited to GUI applications. Having a good debugger integrated with my code editor is basically the reason I use an IDE instead of vim. Stuff like Vimspector exist but are way more work to use vs. a GUI equivalent.

I think the interesting thing with debuggers, though, is that I relied heavily on debuggers back when I was relatively new to programming (maybe the first 10-15 years or so), but once I started to feel like I knew what I was doing--and the stuff I was doing became a lot more complicated--debuggers started to feel a lot less useful and even frustrating or limiting... particularly so given that to actually make a debugger work really relies on you buying your entire project into some unified concept of how execution will happen, as the ability to step across IPC/VM/network boundaries is otherwise a pipe dream. I thereby only feel like I get value out of stepping through some code only once every year or two, and gdb is more than good enough; otherwise, I always make sure I have really good mechanisms for logging and error handling, and leave the debuggers for when I'm teaching someone how to code.

Re: Vim After 15 Years (2017)

#74

Post by johnthedebs »

decafninja wrote: post #63

I would still love to learn vim if only for the nerd credentials. However I cannot imagine how I would reproduce the workflow to even come close to approaching my current productivity level with VS Code. I'd love to sit down with a vim expert for a day and see how much of my workflow I could replicate.

I'd be willing to take you up on that (well, maybe an hour or so rather than a day). I feel the same about vim - there are certain workflows I have that I can't adequately recreate in other editors, so I keep coming back. I'm curious what your workflow looks like.

Re: Vim After 15 Years (2017)

#75

Post by throwaway_au_1 »

I would like to add my perspective to the mix, as it seems Vim pops up here every so often and commonly the discussion becomes one of Text Editor Vs. IDE capabilities.

As I get older (33 now), I feel more and more annoyed by Things That Just Work TM changing on me for (IMO) no good reason. There are very few applications that I update as soon as I'm notified, because more often than not, something changes which at best disrupts my workflow and at worst breaks it. It seems as developers we are both best placed and very much expected to cope with this onslaught of change in our tooling. But when something that worked 2 days ago stops working, to me, that's only an impediment and I feel zero excitement for whatever improvement might have justified it. IMHO.

To me, Vim is a stable, battle-tested, and (IMHO) quite ergonomic way to write and modify code. At this point, I know what I'm doing when I write code (mostly.. maybe), how I want to do it, and I only want to do those things the way I want to do them. To me, Vim is my workshop, a workbench with my tools laid out on it exactly where I want them. Something like VS/VSCode feels like a public space with toolboxes everywhere, which I have to step around to work. I have no idea what's in some of these toolboxes, nor do I care, and I'm pretty sure I saw a lawn mower in here somewhere.

Obviously some people out there, people with a brain wired differently to mine, can work productively or even enjoy that kind of environment, but that's not me. At the risk of sounding like a wanker, I just like the zen of working on some code without all of the noise, in the same way I've always done it. It feels good to be efficient. Hell, there are enough self-inflicted frustrating moments in software development without my tools turning on me, too.

So I use Vim because I'm happy to sacrifice the incredible, broad capabilities of something more for a tool that gets out and stays out of my way, and that I know has no agenda beyond doing exactly what it says on the tin (and maybe soliciting some donations for Ugandan children).

Re: Vim After 15 Years (2017)

#76

Post by Scarbutt »

kazinator wrote: post #36

Another Vim tip: I use a plugin called bufexplorer. I patched bufexplorer.vim with this: if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0 nnoremap \ :BufExplorer endif What that does is make the buffer explorer's window accessible just by hitting backslash twice. The \ key is the default key in Vim. So \ means \\. Bufexplorer lists the open buffers one per line in a window that is searchable.…

I settled on fzf.vim for that (since I'm already using fzf on the terminal) which also has other niceties.

Re: Vim After 15 Years (2017)

#77

Post by cersei »

I've grown tired of big proprietary software, even if it's open source. Companies like Microsoft will keep doing whatever their business whims dictate, deprecating tools, etc... I want to live in a world where I'm in control of my software instead of constantly adapting for reasons that have nothing to do with how I like to work.

I also don't like the common paradigms like having a cockpit of information in my face at all times. I want the information that I need magnified and the ability to dig into it with intentionality in whichever way I choose.

When working with text, I want text in the forefront, not widgets and GUIs. Those are some philosophical, but also pragmatic reasons for prefering the shell based tools and Vim. If there is a visualization that is better conveyed graphically then yes, I can of course open tools for that purpose.

Luckily I'm able to use Vim for my workflow, but I totally get that it's not always possible or feasible.

Re: Vim After 15 Years (2017)

#78

Post by throwaway_au_1 »

sibit wrote: post #43
aidos wrote: post #13

Earlier quoted context omitted.

You have to invest time in your vim setup. There’s a whole lot built in that you need to learn, but you also need to customise it to your workflow. In terms of searching through multiple files, I use Telescope with ripgrep and fzf. It’s an insanely slick workflow that allows me to jump around code faster than anything else I’ve used in my last 25 years of coding.

This, 100%. It took me an hour the first time I configured neovim and another hour when everything broke during the v0.8 update but the ability to navigate multiple files without touching my mouse make it worth the effort. I still have to use Visual Studio for {dayjob} but the Vim binding plugin makes it (almost) tolerable. The icing on the cake is when I need to SSH into a server to debug some PHP or JS on a testing…

Regarding the last part of your comment: you may get some value out of this plugin, https://github.com/chipsenkbeil/distant.nvim, https://www.youtube.com/watch?v=wVAsbpByQ3o.

I've not used it but your use case made me wonder if there's a nice way to do it, as I regularly SSH into my NAS and RPi's, so I had a quick search.

Re: Vim After 15 Years (2017)

#79

Post by ithrow »

scruple wrote: post #20
Trufa wrote: post #9

It's alway pretty fascinating to me that people can actually be productive without an IDE. I've tried several times Vim and I just don't get it how you can live without certain functionalities, I'm sure that with enough tinkering you can get pretty close but, for example, search seems to always be kind of a pain in the ass for the complex queries with regex through many files and stuff like that, specially the presen…

When I need an interactive debugger, I alt-tab into a JetBrains product or VS/VSCode. The only time in my career that I wasn't primarily developing inside of vim/neovim and now Emacs was when I was working on a .NET team.

Why did you switch from vim/neovim to emacs?

Re: Vim After 15 Years (2017)

#80

Post by Scarbutt »

lordgroff wrote: post #47
statico wrote: post #29

Author here. Many will be disappointed to know that I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course). I've been meaning to write a follow-up article, but unfortunately writing is low on the priority list. The main reason is that these days, when I _am_ coding, I mostly write TypeScript and React on my local machine (not much SSH these days), and VS Code Just Works™. I tried twice…

Interesting, I just switched from vs code BACK to (neo)vim. For me the killer feature of vscode was remote, but imagine my surprise to see that was one of many proprietary things in the platform. And then I discovered mutagen, and that opened up my avenue for thinking about neovim again. The neovim lsp story with lspzero is as pain free as I can imagine things to be, so that also helps. In this day and age for the la…

Finally, for the way I like to work, the terminal is often the IDE. One thing I couldn't ever get used to was terminal inside the editor rather terminal being the primary thing. It's why my many attempts at Emacs failed too.

Emacs can run in a terminal too, that's how I have been using it forever inside tmux.

Post reply on HN