Get the top HN stories in your inbox every day.
jb1991
H12
You are not alone.
If there were a GUI editor that had 1st-class Vim keybindings, native LSP support, fuzzy finding, and convenient file management tools a la Ranger, and optionally a built-in terminal, I'd switch in a heartbeat.
OniVim2[0] looked really promising, but the project has unfortunately stalled after the creator had to step back for personal reasons.
iamunr
OniVim not getting finished was soul crushing. :(
aftergibson
Honestly I suspect that’s how the majority “use vim” these days. When I’m on the command line it’s a great lightweight editor, but trying to turn it into an IDE competitor is when the wheels start falling off fairly quickly.
jng
I couldn't believe the lack of support for the dot command in vi emulation in Xcode. Emulation is quite complete, mostly missing regex and ex command support (but even a vi mode that way it's still very usable), but without the key component that is dot command repetition, the whole vi/vim experience is ruined. There must have been some heated conversation at Apple, someone who knows and cares about vi/vim poured a ton of love into getting that right, and they must have felt the pain of not including dot command support.
Just hoping they will address that in a future version of Xcode.
nsb1
The dot command is always what seems lacking in the various emulation layers. Either it doesn't work at all, or doesn't work the way you expect. As a dot command addict, this makes me sad.
jb1991
The weird thing is that is just isn't there in Xcode in any form, yet is the most time-saving feature of the vim keybindings.
jb1991
that one missing dot operator in Xcode is almost enough for me to use JetBrains AppCode instead
diehunde
It depends on the language you are using and maybe the size of your project. I did Ruby, Python, and Go development for years using only Vim and really enjoyed it. But the minute I started working on big Java and Scala codebases, I started struggling. I tried different LSP, completion engines, and debugging plugins, but I couldn't find the proper setup. The IDE Vim modes are decent these days but still lack those more advanced features to manage your buffers and windows for example.
cehrlich
Yeah, I also use VIM bindings in VS Code and love it. When I'm at my desk, in the zone, writing code, my hands pretty much don't leave the keyboard. But when I'm leaning back, browsing through files, etc. I just need to press 'i' once and I have a "normal" IDE.
I couldn't imagine not being able to hover my cursor over something to read its type definitions, cmd+click to go into whatever I'm clicking on, etc.
Sometimes I see one of those videos of a fully tricked out NeoVIM and it looks tempting, but I know I wouldn't actually like it.
matwood
I just like modal editing, and know vi keybindings for the most part. Those bindings are also mostly consistent whether I'm in Intellij, VS Code, or some random Unix machine.
I'm sure some vim expert would be annoyed at my mouse usage, but like you said, there are tons of useful features exposed.
Spooky23
The beauty of vim is it has a rich feature set and is ubiquitous. The problem with the other vim inspired apps is they aren’t there!
A couple of years ago I helped a friend out with moving some stuff off an ancient Solaris database server somehow still in production.
Iirc it was Solaris 2.6… other than remembering which Unix tools were shipped broken by Sun, I was able to function right away. Shockingly, I even retained muscle memory of some of that database commands after many many years! :)
blahgeek
You should try emacs with evil (you may start with Spacemacs). Evil-mode is the best vim emulation layer I’ve ever seen in any editors except vim.
jb1991
I used evil for about 2.5 years. It was pretty good but still not the same.
olalonde
I would probably use Vim mode in VS Code if it supported NERDTree and I didn't have to reach out for my mouse at all.
mtlmtlmtlmtl
I used Spacevim for a few months. But ditched it and Prelude for Emacs for the same reason. These things download huge source trees of config files that are painful to change, import huge amounts of extensions that will have all sorts of broken interactions, and the documentation leaves much to be desired when trying to solve these internal issues.
In the end I settled for vanilla emacs, where I gradually build up a configuration. Once a week I pick something that's been annoying me in the past week and do the configuration for that by hand. This way I avoid bloat and it keeps things pretty sane in terms of configuration complexity. Also I get plenty of time to learn all the shortcuts in my setup as opposed to having a confusing mess of 30 extensions to learn all at once.
0x4FFC8F
What you mentioned is pretty much the way to go. You work on your config on the weekend what you thought was missing throughout your week. I wish everyone tells that the people starting out with vim/Emacs.
oblio
> What you mentioned is pretty much the way to go. You work on your config on the weekend what you thought was missing throughout your week. I wish everyone tells that the people starting out with vim/Emacs.
If that's the way to work with vim/Emacs, that would basically kill all mainstream interest in them.
"Work during the week so you can work during your weekends" is not what most people want.
mtlmtlmtlmtl
The whole point for me is that I pick something very constrained, so that it's fairly quick to do, maybe taking half an hour at most. This avoids spending hours on my editor at any one time which is infuriating
Accacin
I love neovim and vim, but personally I've found that configuring the LSP has been very tedious and prone to breaking. For the last few months I've been using LunarVim, but always felt that it did too much and I felt it hard to configure.
The last few weeks though, someone tipped me off to: https://github.com/brainfucksec/neovim-lua
It's basially a neovim config that's not minimal, but very reasonable. You can install and all the LSP config just worked. I also found it very easy to configure and set up to my liking (added telescope, etc.)
If anyone out there is looking for a great base to start their own neovim config, try it out!
jamespwilliams
https://github.com/jamespwilliams/neovim-go-nix-develop
The above is my attempt to create a minimal Neovim configuration that uses treesitter and nvim-lsp (albeit only for Go).
It uses Nix, so if you have Nix installed you can immediately try the configuration out in a self-contained development shell.
It’s too minimal for everyday use, but could be of inspiration.
christophilus
A lot of gatekeeping in this thread. I have my own grass fed, organic vim config the way God intended, but I think Spacevim is a great way for someone to dip their toes in the water. Just because someone uses a pre-built config doesn’t make them a lesser nerd. Also: I have learned of some handy plugins by following the project.
johncoltrane
"I don't want to learn all that Vim stuff and configure it myself so I will let someone configure it for me and learn their stuff instead."
least
I have my own configuration for vim/neovim, but there's a lot of faffing about finding plugins and tweaking settings to suit my workflow. The end result is kind of a sort of functional stack but without much consistency since it's evolved over time and I simply don't want to refactor it into something more sensible with less conflicts.
Something like SpaceVim kind of makes it so someone doesn't have to concern themselves with that because someone designed the entire thing from the ground up so you're less likely to run into issues that someone who's gradually built up their vim config over time would. That isn't even mentioning the fact that it all hypothetically just works together and you can be productive actually programming out of the box with something like this.
I think for someone that is interested in using Vim (or Emacs, for that matter), these premade configurations with their own superset of paradigms seems like a much better approach to going about it. They can, after all, switch to building out their own config down the line if they feel the need or desire to.
johncoltrane
Someone interested in $THING would be better off learning $THING directly rather than tip-toeing around it.
The argument that they can still decide to do it properly when they want is not grounded in reality. People get used easily to those things so two things happen in those cases:
- they get very frustrated by the real Vim, - they try to replicate their previous ready-made config anyway.
It's all just some elaborate avoidance strategy.
least
> Someone interested in $THING would be better off learning $THING directly rather than tip-toeing around it.
This is not really the universal truth that you think it is. I remember when I learned to drive my father started me on his car with a manual transmission. I skipped gears, Started from a stop in 3rd gear, and had a whole lot of frustration trying to deal with both the concepts of driving the car, the rules of the road, and trying not to completely destroy the clutch of the car. I switched to learning on my mother's car, which was an automatic. I gained confidence on the road and then I went back to learning how to drive stick. This resulted in a much easier time for both me and the clutch. So no, I wasn't better off learning it directly. The same can be said for something like walking and then running, or learning how to program. They typically don't start students off learning to write Assembly even if their intent is to be an Assembly programmer. Training wheels on a bike exist for the same reason too. Can people make this approach work? Sure, but that doesn't mean it's better. In fact I think in quite a lot of cases it's way worse.
> they get very frustrated by the real Vim
They are using the "real" Vim. You being weirdly gatekeepy about this doesn't change the fact that they're using the same application that you are, except they loaded a config different from yours. There is a list of different keybinds from vanilla vim in their documentation and you can disable them with one line in your config. Pretty much all the typical vim paradigms are exactly the same.
> they try to replicate their previous ready-made config anyway.
kind of their prerogative and one of the nice things about extensible programs like vim is that people can do exactly that. I could change vim to use CUA commands, be mouse-focused, and default to insert mode and I'd still be using vim.
kirillbobyrev
After almost 10 years of tinkering with Vim and fixing it every time a random extension updates and breaks my whole setup, that would be exactly something I want.
drekipus
I'm pretty sure after 10 years most vim users stick to a vanilla 5 line config for this very reason.
tempodox
How would you know? It's certainly not true for me.
rag-hav
> fixing it every time a random extension updates
You could pin your extensions in packers. Not sure about other plugins managers though.
kirillbobyrev
Yes, I was doing that at some point. But then the problem is that
- I work (or rather workED until a month ago) on LSP implementation for C++ (clangd) and I frequently need updates in the client - The client (Neovim LSP client) is being developed quite rapidly
For the reasons above, I did update the LSP plugins and Neovim versions quite a lot. And (in my experience) that is the thing that breaks the most over the past 2-3 years. Everything else is kind of OK, but it doesn't make much sense without the LSP. I could update only some plugins and keep the others at a fixed version, but then overall I'm not getting bug fixes & features which makes me kind of sad (that's why I started building my ultimate (Neo)vim setup in the first place).
I guess I should really stick to just a couple of basic plugins and throw everything else out.
avgcorrection
This is for people who happen to like the “space” setup already. Not for people who just want some random configuration.
What’s the difference between someone who uses vanilla, unconfigured Vim and someone who uses unconfigured SpaceVim? Merely that one of them likes vanilla Vim and the other one likes SpaceVim. What’s the problem with not configuring things if you don’t want or have to?
Also the mock quotation thing is way overdone around these parts, jeez.
johncoltrane
> This is for people who happen to like the “space” setup already. Not for people who just want some random configuration.
It is used by and marketed to both populations.
> What’s the difference between someone who uses vanilla, unconfigured Vim and someone who uses unconfigured SpaceVim?
As if those were the only possibilities.
> What’s the problem with not configuring things if you don’t want or have to?
No problem and no idea where that comes from.
themodelplumber
See also: Gentoo vs. Debian, Arch vs. Mint, groceries vs. takeout, etc etc...
iasay
I’m in the same space but I found the best option was just to not bother with anything past the default plugins. I type one simple vimrc from memory that is about ten lines and job done. Also I only use a fairly common subset of commands.
I found this was a good compromise because I jump around all sorts of systems and broken ass container hosts so any vi variant is home then.
ivlad
You may like this approach: https://www.atlassian.com/git/tutorials/dotfiles
If you keep your dotfiles (vimrc included) in a public repo, checking them out to every new system may become a useful habit. Or you can even do curl ...| bash to setup your work environment every time.
iasay
Im not allowed to do that. I work in high security environments usually. We can’t even talk to GitHub from those nodes. And if we could we’d be shot for doing it.
Pulling stuff out of GitHub regardless of the repo into a production machine should be frowned upon anyway.
rgoulter
Vim (and its cousin, Emacs) are quite terrible out of the box, with the excuse that it's "configuration over convention".
It's not efficient for many different developers to each learn how to configure Vim to the point where they can get an effective editor out of it. - For this, a shared configuration / distribution saves a bunch of time.
It does make sense for developers to learn vi keybindings (so that they'll be able to use a vanilla vi in a limited environment), or to learn how to customise their programs for their particular situations.
To my understanding, the non-standard keybindings in distributions like Spacemacs provide are consistent, well thought out, and discoverable. (Which won't be the case with each ad-hoc customisation).
I do get the impression that Spacemacs (which I think inspired this project) adds a layer of abstraction too many, such that users who are stuck with Emacs might not have the capability to get themselves un-stuck without effort.
cutler
Plus there hasn't been a stable Spacemacs update in years. Telling users to use the dev branch doesn't inspire confidence.
pweissbrod
I look at it differently. If vim is a useful tool in your daily workflow then it's probably worthwhile to invest time into customizing it and enhancing it with plugins.
The open source landscape of plug-in development is under constant evolution and it can be quite a time sink staying on top of the latest and best tooling.
I see SpaceVim as something similar to a Linux distribution. The maintainers offer the work of selecting various packages inversion combinations that harmonize into a consistent system.
And just like any Linux distribution you can agree or disagree with the packages they choose or the default configurations it comes with.
I end up using a somewhat heavily customized SpaceVim that I personally like but it's my opinion the distribution is a very productive foundation.
slig
It's an option for newcomers, and IMHP way better than just sticking with VSCode without even trying Vim because it's too hard to use or setup.
johncoltrane
Here is another option: learn Vim in Vim itself.
alberth
It’s too bad that Onivim2 development stopped.
It had the potential of being all the great things of both SpaceVim + VS Code combined into a native app.
cercatrova
I've found Helix Editor to be a good successor [0], although it's still in development. Vim-like modal editing with fast performance due to being written in Rust rather than Electron.
cassepipe
I was supporting Oni2 for the same reasons, a work-out-of-the-box fast modal editor but a Gui would have probably meant leaving behind a terminal based workflow.
I have also been seduced into Kakoune's way of doing things although not enough to make the jump from vim, which I hate but can't live without.
Helix really hits that sweet spot of a fast work-out-of-the-box kakoune-style terminal editor. Time to make the jump.
cercatrova
Unfortunately the reason I switched back to Neovim is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.
divan
Some anecdata. I've started using Helix too, and found it surprisingly good (relearning some not-so-vim stuff wasn't a problem). But I returned back to NeoVim purely because of... Copilot. Hard to code now without Copilot, and it's only available in VSCode and NeoVim ¯\_(ツ)_/¯
cercatrova
Yes, that is also why I came back to Neovim. Another con is that Helix doesn't have plugin support yet, so one can't really add new features, even if most of the popular ones are built in, like tree-sitter.
konart
How can it be a successor to Oni if it's terminal-only application?
cercatrova
Due to speed and vim-like editing, with certain things like tree-sitter support built in, similar to how Oni has things built in. With (Neo)Vim you'd have to configure that yourself. That it's terminal versus GUI doesn't make much difference to me, since as long as it shows text/code on the screen, I don't really care how it displays it.
thecatster
I was really hope for that to turn out well, but alas, but to Emacs or Neovim I go. I even paid for an Onivim2 license.
thomasfortes
If I had to bet, I would guess that the ReasonML > Rescript drama/change killed a lot of the momentum in the community.
triyambakam
I'm only vaguely aware of the change. Can you elaborate?
d3nj4l
You can read about the ReScript change here: https://rescript-lang.org/blog/bucklescript-is-rebranding
I wouldn't go so far as GP as to call it "drama", but the split left Reason without a reason (pun intended) to exist or any activity for that matter. Most of the people who liked Reason for frontend usecases moved to ReScript since that at least had some momentum behind it. Since the split, Reason itself has been largely on life support, with no significant changes and almost no forum activity in the past year. So newcomers to Reason see a dead community for a language which is a syntax extension for another language with a (relatively) alive community. The fact that Reason hasn't seen a surge in enthusiasm corresponding to the enthusiasm in the OCaml community with the advent of 5.0 and multicore is proof enough that Reason is dead, and projects written in Reason should probably consider moving to OCaml entirely considering there are planned changes to the OCaml syntax for effects which I don't think are going to make it to Reason.
Some people in the Reason world blame the ReScript people for this, which I think is entirely misplaced. The only reason (pun not intended this time) Reason has died off is that there is absolutely no clarity on the future of Reason. The creator of Reason, Jordan Walke, has been entirely MIA for about two years now. A version 4.0 was planned in 2020 and as of now hasn't come up. This issue was opened in Nov 2020 asking for future plans and is still unresolved, and the latest comment from a new developer just makes my point: https://github.com/reasonml/reason/issues/2634.
thomasfortes
The creator of bucklescript (ReasonML/OCaml to JS compiler) decided to drop ocaml support and gather the already built community around his new project (Rescript) and it wasn't well received by the part of the community that were interested in ReasonML (and OCaml) for native or hybrid applications, which is kind of obvious since:
1. Rescript is not ReasonML/OCaml, it is a new language.
2. Rescript doesn't compile to native code.
Forks were being discussed, the creator didn't like the criticisms of his decision (which came as a surprise for most of the community), people didn't liked having the rug pulled out of their feet, aggressive comments were made, people were angry and the community got separated between web and native, both weaker than the united one.
TL;DR; The creator decided that his project was for web only, alienated the native developers out of the blue and shattered the community.
Sparkenstein
The reason why you shouldn't go for obscure frameworks for new projects and stick to popular libraries like vue react
thomasfortes
Funny thing, ReasonML (the alternative syntax for OCaml) was created by Jordan Walke, who also created React.
The cool thing about Bucklescript is that it generated pretty readable javascript, so dropping the compiler and working with the JS files was pretty easy, which is what I did with a project that I was working when the drama started, just used the generated js files and slowly replaced them with typescript when needed.
garren
How does this compare to LunarVim? LunarVim seems to work pretty well, although I regularly get stuck after an update.
linsomniac
I used SpaceVim for a month or two, and it was good, but I switched to LunarVim and it's amazing! Been using it for ~6 months.
As you say, updates are a bit rough. I've given up on updating,and periodically I just reinstall it from scratch (a fairly painless process, they did amazing at making it easy to install). I figure this is comes with the territory of a rapidly evolving package.
The Treesitter and LSP features give me real-time code intelligence that I had been missing, and has made porting python2->python3, especially with type annotations, so much easier!
agarren
I’ve been doing the same as far as reinstalling when an update goes awry. Not super convenient, but not too painful either. Overall I’ve found the LunarVim experience worth it. I think you’re right, it’s a quick moving package and bumpy updates are par for the course.
I’ll give SpaceVim a shot. LunarVim is great, but it’s good to see what else is out there. I love vim in general, but I’ve found myself killing too much time fine-tuning/breaking my config. LunarVim more or less works out of the box and gives me what I want. I’m curious to see what SpaceVim has to offer.
linsomniac
I went to LunarVim to try to get out of the business of fine-tuning vim configs and custom configs, so I'm trying to keep my changes from stock as minimal as possible, adapting where possible. One of the things that I can't adapt to is ESC+j/k moving the current line up or down, I was always accidentally moving lines around, sometimes not noticing it until code blew up.
kamaal
I was not able to even install/build LunarVim.
I think these packages need to ship with homebrew or atleast some sort of an installer. Building them seems to be very hard for people who just want to use it, and not go down hacking rabit hole.
ngai_aku
It’s a little comical that SpaceVim has reached v2.0 while it’s inspiration, Spacemacs, is perpetually on v0.200. Anyway, congratulations to the SpaceVim team!
onelovetwo
Version numbers don't really anything when comparing two projects.
Usually it actually means the maintainer is trying hard not to make breaking changes (bumping the version).
eimrine
ASCII graphics of "SpaceVim" on a screenshot seems broken.
bobbylarrybobby
Yeah, looks like a backtick is in the p where it shouldn't be.
smegsicle
or is escaped where it shouldn't be
danschumann
Oh wow, I'm a vim user and i have yet to hear about this. It's basically a version of vim with more goodies? Does it run in terminal and gui?
smitty1e
As a Spacemacs user, the idea is a distribution that harmonizes a package collection into "layers" for Good Justice.
Using the space bar to drive a text interface is a win over the stock emacs key chords, which wear out my left arm/wrist.
Vi's modal editing, once understood, is a general win, too.
Spacemacs blew my mind by setting up a Language Server Protocol (LSP) environment for python with almost zero effort. Not sure if SpaceVim is quite as broad in its feature set.
konart
Not a version but a complex configuration that can be used with Vim or NeoVim.
shmerl
What plugins are used in this screenshot?
https://cloud.githubusercontent.com/assets/296716/25455341/6...
p10_user
I’ve come full circle. I now don’t use any config, instead writing file specific setting with modeline. Although now I’ve started collecting modeline templates I need get bound to some hotkeys. Back to the .vimrc I go.
samrocksc
I was the same way to be honest. I ended up taking the parts I liked from spacemacs/lunarvim and adding them. I also started doing all my configs in lua, because it's great
Get the top HN stories in your inbox every day.
It's possible I'm one of the few who thinks the best thing about Vim is the keybindings and other nifty features like macros, while everything else is archaic and frustrating, hence why I always looks for a good vim mode in a more modern IDE. Though often the vim mode is lacking (i.e. Xcode doesn't even support the dot operator to repeat a motion, which is astounding), and so we get back to square one with using vim again.