Hacker News Reader

Comment by extr | Hacker News Reader

So, I just gave it a shot. Seems pretty nice, definitely pretty syntax highlighting and basic autocomplete was simple to get up and running.

However, I think this project has the same issue as basic VIM/NVIM, in that if you're coming from something like VS Code it's not super obvious what plugins account for what functionality, or how you can replicate your workflow. For example, I had to google "Treesitter", which seems to be an AST parser. Okay, that's awesome that they have that, but what exactly do that do for me?

On top of that, immediately ran into issues with the autocomplete not picking up my venv, not completing function signatures, etc etc. And diving into the config now apparently means I need to learn the lua language.

Sorry don't mean to rant to you specifically. Just secretly wish I was one of these 20 year VIM guys with perfectly honed configs, but not enough time in the day.

View on HN

I'm one of those 20 year VIM guys. After about 2 years I had a config that I haven't touched since. I could easily go without it, too, and frequently find myself on servers that I forgot to copy it over and didn't even notice. I usually only notice when I start trying to paste things (pastetoggle).

You need to learn VIM itself, not the configuration. Just leave the config alone unless you are trying to do anything with tab spacing, or shut off some annoying feature, really. My config is ~40 lines long and just sets some basic things, and uses zero plugins.

I think the problem is that people are focused too much on tooling than work/coding. This is true of almost every developer that I've noticed. Leave the tool (mostly) alone, just use it. Tooling creates so much wasted time.

This is my experience as well. I've witnessed colleagues and other developers boast about their vim configurations and plugin ecosystems (and supposed gains in productivity) non-stop ever since I started working as a software engineer professionally.

Yet here I am with an almost out-of-the-box configuration, not a single plugin and my productivity/output is usually considered (far) superior to those of my peers.

I've never understood this widespread obsession with tooling. It's virtually never been the bottleneck for me in any software project I was involved in. The main obstacles I've found are usually of social and/or organizational nature, followed by sometimes (far off) the involved technologies. Tooling isn't a concern.

I don't see the connection between the two things that you seem to be making: namely between having a bare setup and an increased productivity.

We only have your word for it and it doesn't look factual to me at all.

F.ex. in Spacemacs the ability to fuzzy-find file names and file contents has saved me a lot of hours in the last several years. I absolutely don't see how I would work faster on those 1000+ files projects if I didn't have that functionality.

Want to elaborate on that point in particular? How does a naked editor help you in this scenario? Or will you claim that you know what's where in every single file in the projects you're working on?

Sorry to be a bit flippant but IMO you and your parent ventured way too deep into the "let's pat each other on the back about how minimalistic our environments are and how productive are we as a result" territory. Or "those crazy youngsters making their lives harder for no reason at all, am I right?" one.

I never said anything about not trying new tools, I'm talking about obsession, and it's become an addiction in some people. This is younger people than me AND older people than me. To the point that they aren't USING the tools they are learning, just learning how to use it in such depth that they paralyze themselves. It's not just one tool, either, they'll learn all the tools out there, find ways to solve problems in 10-20 different ways, then not solve anything applied or practical. When it comes to debugging they are just paralyzed because they don't know how the programming language works, just the tool.

It's perfectly fine if you are using the tool and have found a happy medium, which sounds like you have. You found a tool, you used it. You didn't spend years tweaking the tool, learning how to make it look pretty, then move on to another tool and bend that tool to basically be a clone of the first one you used.

I never said anything about a "bare" setup. I'm saying you should find what works for you and use it.

I shouldn't have to teach people who know how 900+ WMs/DEs/IDEs to work what a hosts file is, why setting 777 on every file to solve any problem is a bad idea, or how software licensing works, but I have to do it regularly and it causes clusters to crash, deadlines to be missed, and bills not to be paid because they're too busy customizing their fancy redundant solutions to problems they aren't solving. Or installing a big 10 server cluster to solve something that can be done in 10-20 lines of code on a laptop instead with an off the shelf product that costs $100,000/year for one task and then ditch the product entirely.

I don't know why you took this personally...

As for editors vs OS, yeah I mean you have an OS already installed, right? Why create an overlay that does the same thing? Emacs has a web browser in Lisp, why? elinks/lynx/wget/etc exist to do exactly that on the terminal if you have to do a terminal based solution (downloading ISOs on a server, for instance). Or even just use Firefox on your desktop rather than trying 900+ browsers and never concluding which one will work for you, constantly switching back and forth and back and forth...

All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.

Oops, I really did project hard, didn't I? :D

Sorry!

> To the point that they aren't USING the tools they are learning, just learning how to use it in such depth that they paralyze themselves.

Yeah, I've met those. And I completely agree that what they do is unprofessional. At one point you should just sit on your arse and do what you are paid for!

> I don't know why you took this personally...

Same reason why many others do -- I projected. :) Apologies.

> Emacs has a web browser in Lisp, why?

I am sure many would chime in to say how they love never leaving Emacs or how back then good email clients and web browsers weren't a thing -- but I am with you here, I think the effort and tool duplication must absolutely stop already.

There aren't very many of us the programmers in the world (I mean those who get sh1t done) and we shouldn't spread our efforts in meaningless individualism.

> All I'm saying is use the tools. Customize it as needed, but don't become addicted to customization for customization's sake.

Yep, 100% this. I actually do my very best to customize very little. I spend a great amount of effort [every now and then] to find the canonical way a tool [is expected to] work/works and just do a very thin layer of customization on top of that, versioning it with GIT and overall making sure I can nuke my $HOME from orbit, clone a few repos on a new machine, issue a few installation commands and be on my merry way.

Sorry, I guess I wasn't quite clear. I didn't mean to imply that a bare setup leads to better productivity.

The point I was trying to make was that constantly playing around with your tooling (configs, plugins, etc.) leads to very marginal productivity gains at best, especially considering the significant amount of time many developers invest into it. This is based on my observations and thus purely anecdotal.

Pick the proper tools for the job at hand once, learn them. Make minor adjustments if absolutely necessary, but don't get obsessed with tweaking.

The true potentials for gains in productivity lie in many other areas IMO; organizational/social/collaboration matters in your org, actual engineering skills, and so on.

> The point I was trying to make was that constantly playing around with your tooling (configs, plugins, etc.) leads to very marginal productivity gains at best

Oh I completely agree, the problem is that is expected in many areas -- especially the JS stack (hence why tools like `esbuild` started emerging eventually).

I agree that many devs just "pimp" their setup all the time and that's not productive. Yep.

Sorry if I vented too hard; it did seem like you're one of those guys that scream "real men use vi!" but since you are not -- my apologies for the not very constructive comment earlier.

  > You need to learn VIM itself, not the configuration.

But then he gets a text editor, not an IDE.

Signed, Another 20 year almost-no-config VIM user.

Treesitter gives you fast, accurate syntax highlighting, indentation, and selection based on object type.

As far as the 20 year vim guys, I'm a 30 year vi guy and looking to get out of maintaining that mess that my vimrc has become. Trying lunarvim and kakoune.

Check out Helix. It's based on Kakoune and integrates TreeSitter. It's only 04 though for now. Worth keeping an eye on I think

https://helix-editor.com/

I feel the same way after diving into the NVIM world a while ago. I put in the hours, spent like 10 hours trying to setup the environment to my liking, and ran into the same issues as you, autocomplete being a pain in the ass, having to figure out what these all plugins are etc..

But at least I found out I can just clone my vim plugins from git repositories with vim-plug, which was an improvement over my previous pathogen setup.

VSCode is just killing it with the feeling of having a complete setup and everything actually working, vs having to spend days figuring out how to setup a VIM environment these days.

On the other side of the fence, I tried VSCode and the heaps of issues I faced with basic editing was so off putting. Even basic IntelliSense stuff like suggesting local variable names reliably and timely. Just give me my dumb trusty keyword completion.

> if you're coming from something like VS Code it's not super obvious what plugins account for what functionality

How do you know what plugins account for what functionality in VSCode?

Open the plugin-manager and read their documentation. But usually you need to install them yourself anyway. And because it's a GUI, discovering things is very easy. Just click and read.

  > But usually you need to install them yourself anyway.

So, not unlike VIM?

Yes, very unlike VIM. Have you ever used VS Code? The second you open a file with an type you haven't used before, the application is like "Do you want to install the extension for this?". Like 2 more clicks and it's done. VIM plugin discoverability literally could not be worse.

I see, thanks.

Maybe I'll write up a page with one-line summaries of the most useful VIM plugins - not only the IDE plugins - to help people find what they need. Any ideas for plugins or information to include welcome.

I'd thought you were referring to after you've installed a plugin (or it got installed for you) and you wanted to know which plugin was doing a particular task.

This is actually a problem in vim and emacs, but to my knowledge it's exactly the same problem in VSCode.

If you're talking about discoverability of plugins for certain functionalities that you're looking for, then yeah, it's easier in IDEs like VSCode because plugins tend to do lots of things (e.g. you don't install a plugin with the Java debugger, another with Java syntax highlighting, another to run tests .... it's just THE JAVA PLUGIN).

Spacemacs solves that for emacs by creating "layer"s which essentially bundle a bunch of emacs packages together so that you only need to install THE JAVA LAYER instead of the 10 packages you actually need. Not sure if NeoVim or LunarVim do that, but should be pretty simple to do.

> I'd thought you were referring to after you've installed a plugin (or it got installed for you) and you wanted to know which plugin was doing a particular task. > > This is actually a problem in vim and emacs, but to my knowledge it's exactly the same problem in VSCode.

No, it's not the same, because in VSCode you have ways to discover plugins and their purpose with basic knowledge. Just go through the list and read their description and find the one that matches the effect you search. They are even so well documented that they list the shortcuts, commands and settings they use automatically. And other parts of the app are evenly open and supportive. And if you not found it at the plugins, just open the settings and use the search. It's very easy to come very far out of the box with VS Code.

On vim and emacs on the other side you have simply no way at all to figure something out from the baseline. Until you learn to master them well enough to use their ways of doing things, you are just lost and abandon and can only hope to find some solution by googling for it and test things till it somehow works.

VS Code is a GUI, and even a very well-made one, and as such it's very open and self-descriptive. While vim and emacs are mostly non-descriptive at all and very cryptic until you dived deep enough to learn your ways. Both have their advantages in their own, but for this specific case, the cryptic completely loses.

> Spacemacs solves that for emacs by creating "layer"s which essentially bundle a bunch of emacs packages together

VS Code has bundles too. But it seems they are not that popular because in the end they are often too opinionated.

> On vim and emacs on the other side you have simply no way at all to figure something out from the baseline

Do you actually know emacs? It's the most well documented application I've ever used. And it's famous for exactly that and it has a "culture" of including INFO pages for everything. I completely disagree with you on that.

You can use emacs like you use VS Code, clicking around and letting lsp-ui render those colourful help popups everywhere... I agree it's a bit more difficult to install the right packages, but that's the only difference I see between them. Once they're installed, it's basically the same, you need to just "know" how to do what you need and the tool won't magically teach you.

> Do you actually know emacs? It's the most well documented application I've ever used.

Yes, I'm using it for a long time now. And while emacs has its ways, they are not obvious, nor standard. That's what I mean with baseline, the common knowledge of users. Emacs out of the box is not very accessible, and spacemacs&co. do not change much in that regard. You still need to work on discovering the ways of emacs to gain something from it.

VS Code in that regard is different. It's a GUI and all the user need to know is how GUIs today work, which is common knowledge.

> it has a "culture" of including INFO pages for everything

Barfing out information for anything and everything does not mean it's good or helpful. Emacs documentation is also infamous for how dated and useless it can be, especially for beginners.

> Barfing out information for anything and everything does not mean it's good or helpful.

Right, and every VSCode plugin has perfect documentation?

Nothing is perfect.

As a 20 year VIM guy, my configs are not perfectly honed, I still regularly learn new tricks, and I still feel like there's a ton I don't know.

And will you, on your deathbed, not regret all the time put under making a coding environment work to your liking? I personally can't imagine putting so much of my most valuable asset under what is essentially just editor config. But then again I'm a millennial so what do I know.

The idea is to configure your editor so that it enhances your productivity. E.g. you spend 1 hour on editor config, but then you finish 8h of work in 6h because you work faster.

More likely the improvement is minimal and it’s recovered across many sessions. But still, the net result is supposed to be positive by a large margin.

"The perfect blossom is a rare thing. You could spend your life looking for one, and it would not be a wasted life."

It's a bit like trying to write the perfect piece of software. Some people wouldn't bother with the effort and would instead use something written by others, I mean we all do that to some extent.

It comes down to, why do anything?

If you do want to make anything or do anything, it's never a wasted effort, even though you'll never succeed in doing that perfectly.

https://xkcd.com/1205/

Over a 5 year time frame something that saves one second per day is worth about half an hour of time.

Something that saves 5 seconds 20 times a day is worth 50 hours of work.

Over 20 years its worth 2 hours and 200 hours respectively. It's probably pretty easy to find optimizations in any environment that are trivially a positive investment of what you correctly note is your most valuable asset.

It's like asking a carpenter why he bothers to sharpen his tools.

You can't code effectively if you don't spend time optimizing your workflow, and there's no single thing as important for that as the environment you're actually typing the code into.

weird that venv didn't work. I know conda does. Did you run `:LspInstall python`?

Reply on news.ycombinator.com