Weird. I built my .rc files like 10 years ago, and only edit them about twice a year to add a plugin or modify a keybinding. Not a pain to maintain at all.
Pretty much everyone knows the price of admission to using tools like Vim and Emacs is the time investment in config and learning the quirks.
What the OP is saying that this doesn't have to be a perpetual state. Once you invest effort early on getting it right you often don't need to touch it, beyond a few tweaks now and then. The maintenance burden definitely declines over time.
Then all you need is a storage solution like git and GNU Stow or the various clones (plenty of good ones around or just use a basic dir).
There are a few preconfigured configs on github, ala oh my ZSH but for Vim or Emacs. That's one solution.
But otherwise if you're not a fan of this config heavy approach then it's not for you. Just like using Linux desktop vs Mac. I love the configurability of Archlinux and I've similarily reached a mature point in my configs where setting up a new machine is zero work and I rarely need to tweak it, nor does it ever 'break' (which is a side effect of constant change).
Honestly, I learned to code with vim, and it never struck me as particularly complicated. The commands follow a pretty consistent logic... the defaults aren't great but it took me one google search to find out what a vimrc file is.
emacs on the other hand, even as an experienced programmer, I found near unusable in its default and after a week of frustration with all the inconsistencies and oddities gave up on it. Which is a shame because obviously it is the more powerful of the two. I wish someone would create a modern editor in the spirit of emacs.
Agree on Emacs. Tried to get into Emacs few times because I am not the biggest fan of VimScript (I use it quite often though). So, I thought that it's worth learning Emacs with a proper Lisp underneath. But I failed everytime and getting back to Vim felt just natural and as easy as turning on my PS4.
One thing with emacs is that some Alt bindings do not work over remote connections. Maybe it was my fault but I could not get all Alt bindings to work.
> One thing with emacs is that some Alt bindings do not work over remote connections. Maybe it was my fault but I could not get all Alt bindings to work.
Were you connecting from a Mac to Linux? Emacs on OS X has Esc as meta by default, which means you need to redefine the meta key to be Alt or else it's basically unusable.
I think part of the reason Atom and VS Code use Electron is for cross-platform support. Assuming Github and Microsoft were going for market share, making a native Mac OS editor would somewhat limit their reach.
You're right that emacs without any config is annoying. Check out Prelude (https://github.com/bbatsov/prelude); it's a really nice set of defaults for emacs.
I think emacs is the modern editor in its own spirit: none of the imitations come close.
As a counterpoint, you shouldn't have to tell anybody about storage solutions and preconfigured configs. Once you start doing that, you're talking about solving problems that don't exist in other editors.
Given that there are quite a few editors where people tend not to like the defaults (Vim, Emacs, VS Code, and Atom come to mind, at least for me), it sounds like what you're saying is "editors that beyond the specific set that have these problems don't have these problems", which doesn't seem terrible informative.
Has anyone tried VsVim [1]? It is the best vim experience I've had in any other editor. And I've already tried Sublime's, VSCode's, and others. Most of the vim functions I use are there, but it's been a while since the last time I used VisualStudio, so I don't recall the ones with problem. You can even plug in relative line numbers [2].
Either many many thousands of professionals are blind to the awesome power that is windows plus visual studio or maybe people value different things and having made an informed analysis decided to use other things.
> Pretty much everyone knows the price of admission to using tools like Vim and Emacs is the time investment in config and learning the quirks.
To me, the real hurdle to vim (or emacs) isn't configuration : it's learning vim (or emacs). That muscle memory doesn't come from a .vimrc file, and it doesn't come overnight. Is that what you meant by "quirks"?
Muscle memory only comes after using your editor of choice for a considerable amount of time. With Vim, as a mnemonic, internally talking with the editor is the best way to go: for instance, if you need to change the content of a string literal like "hello world" just think Change Inside ". To me learning Vim is essentially learning a live programming language.
It can be said about anything, but it obviously applies more to CLI based editors since literally everything requires specialized muscle memory. Take a super simple example : Unless I've literally never used a computer before, I don't need new muscle memory to copy or cut out a block of text with VS Code, or Sublime, or Atom.
It's the same story with the muscle memory though. Build it up once, then the effort of learning new things is not very large.
I don't think anybody doubts that there's a steep learning curve and some investment required to get set up, but you get a completely custom user experience out of it. And if you stick with it for years you're definitely getting your investment back.
My point is that after the initial investment in the setup, it takes almost no time to maintain them. In my particular case, I invested about 2 weeks tweaking settings here and there until I felt comfortable with it. After that initial setup, it just gets out of your way.
Personally, my biggest issue is getting vim to work the same way on multiple platforms. I have a mac at work and alternate between windows and linux at home. Each of those has been slightly different than the others. To some extent, yes, once you have the config set you can just leave it alone and be fine. But for me, switching to a full IDE has made life easier.
I'm really intrigued by what all you're doing that you have this kind of problem. I maintain a pretty complex vimrc, and deploying it is normally just a git clone. I've never had any of these issues, and when I started at google (which provides a nice collection of internal vim configs and plugins), combining the two and getting everything set up took me O(hours), not O(days). What are you doing?
I simply updated mvim and :E stopped working on OSX.
I could work around with NERDtree, but its one of those things turned into a timesink when I didn't need it.
Have you considered that your usage is at fault as opposed to vim? Out of 127 plugins installed and even more tried I cannot recall ever having an issue other than having bound a key that the new plugin would have bound.
I feel like the amount of hassle in terms of time spent is probably more imagined than real.
I tried VS Code for a couple months last year. It felt like less of a hassle than vim from 10 years ago. But with pathogen, cloning into .vim/bundle doesn't feel any more burdensome than finding the best plugins on VS Code did.
I use a Github repo + gnu stow. I wrote a little post about it (http://juanda.me/managing-your-dotfiles-with-gnu-stow). Notice that I've made my dotfiles repo private since then so you can't check it out, but the post still draws the general idea.
Mine are on github. If you want to use this setup simply copy and paste the contents of your original files and use the `makesymlinks.sh` script to create the links. It takes me 30 seconds to setup a new computer with it.
I have different needs in my dotfiles for different contexts, so I've created a system where each file is represented by a folder, which contains separate file snippets for each context.
So in my vimrc folder, I've got a work file, a school file, a home file, and a base file (which applies everywhere).
Then I have a bash script that stitches all the relevant chunks together into a cohesive file for a given location. It can even do sub-locations by adding underscores to the name. E.g. 'work_nas' will produce a file consisting of the base, work and work_nas files, concatenated together.
This all sits in a private git repo, and I just manually copy the output files to wherever they belong whenever there's an update to them. I've been thinking for a while about writing a script to copy them into place, but GNU stow looks pretty interesting.
Stow is probably the simplest way to do it. The only weird thing is the directory structure I have with `.` prefixes in order to be linked as I want them inside my home.
Besides that, I don't see how a better way to do it.
I store them in a dotfiles repo that gets pushed to Github occasionally. They get symlinked to my home directory, and I use thoughtbot's rcm[0] tool for managing that. Then I just use a small script that I keep updated to handle installation and setup on a fresh computer. I'll need to take a look at gnu stow now. It seems like it'd be a slightly simpler alternative, and would keep my dotfiles folder a bit better organized.
I do exactly this myself, and it works remarkably well. I had a few conflicts I had to work around between different packages, but the updated vim package directory structure has mostly solved that problem.
EDIT: The biggest problem, for me, is that since they are all dotfiles, they are invisible to normal ls operations within the stow directory. It's a minor nit, but it can be quite annoying to run up against.
I store my configs in a git repo on Seafile/Syncwerk (Dropbox alternative). This gives me a seamless experience on Unix, OSX and Windows where I just have to link to them from my home directory when on a new computer.
Yes, it took an initial investment but now it just works everywhere and maintenance is low.
(Some people say git repos in clouds sync are bad, but I have had zero problems with them over the years.)
Its just bad because the .git folder means that any time you delete an old git repo or anything, you get a fevered email from dropbox reminding you that you just deleted 10000 files.
