Hacker News Reader

Comment by zeroxfe | Hacker News Reader

All this looks really great, however I think I just can't deal with the effort of maintaining these complex editor configurations anymore.

I've been a multi-decade Vim user, until I switched to VSCode last year. It made me realize how much better the user experience can be for an editor. I had all kinds of complex vim configurations and plugins with special cases for linux vs. mac, server vs. desktop, GUI vs. terminal, all of which are a huge pain in the butt to maintain.

If there was one thing I could ask of Vim (or even emacs), it'd be a consistent high-quality default user experience.

(Ofcourse, the default experience in VSCode isn't perfect either, but it took me four lines in settings.json and four plugins (vim, go, eslint, clang) for a near-perfect experience.)

View on HN

I've always felt vim is an excellent editing experience but a lousy project management (ie "IDE") experience. I've also grown tired of the song and dance of setting up vim config and plugins, getting excited when I finally get a decent autocomplete working without stopping to consider VS Code has great autocomplete out of the box.

The problem is vim editing never quite mixes well with other editors. The vim plugin for VS Code is great, but do you let it take over Ctrl? Do you get Ctrl-R for redo, and sacrifice other VS Code usages of Ctrl for example? The vim plugin is also pretty buggy here and there and no matter what, I always find a vim plugin is missing some vim feature I depend on.

It's frustrating in a first world sense. It's hard to have your cake and eat it too with vim.

The real solution to this problem is for IDEs to support an editing frontend interface and then editors to be split into frontend and backend so that really you could use them in the context of the IDE.

The obvious example would be using the neo-vim frontend to interact with VSCode, Eclipse, IntelliJ, etc.

What I want most is a Neo-Vim frontend to org-mode in Emacs, because it would be hilarious and because while Spacemacs is kind of cool it's still not Vim. And org-mode is awesome and unparalleled but vim > emacs all day.

That's what this project is working on: https://github.com/carlosdcastillo/vim-mode -- using neovim as the editing backend to Atom. It still doesn't completely solve the problem of vim and editor key commands clashing.

Another interesting approach is VimR (http://vimr.org/), which is Neovim combined with native IDE addons such as Markdown preview, file tree, etc. The nice thing about VimR is since the whole thing is one cohesive package, the developers can ensure it has a consistent experience. Sadly it's OSX only though.

that's exactly how limetext approached it. one back end, multiple frontends. I think that project is dead-ish though

This is basically what the language server protocol (https://github.com/Microsoft/language-server-protocol) is doing, just in reverse.

Have you considered emacs + evil?

I think emacs falls in the same camp as vim in this regard. Setting up emacs is just as painful as setting up vim.

Check out spacemacs, it works beautifully out of the box.

Spacemacs is only good if you actually use it consistently throughout the day.

From the prompt, it is faster to open a large file in vim than emacs since you have to wait for all of the spacemacs plugins to load.

If you like searchable multiple-choice configuration, there's always customize.

M-x customize

That doesn't help emacs noobs at all. Half the Emacs term still used today 40 years after being coined don't make any sense. Wait - this is not the Window, but the... Frame? What?

Emacs terminology for the uninitiated. http://wikemacs.org/wiki/Emacs_Terminology

frame -> X window

buffer -> tab

window -> tile

I agree. With the caveat that I'm not a vim power user, the IdeaVim plugin has worked well for me. It doesn't have everything, but I haven't encountered any annoying bugs while using it. Plus, IntelliJ / WebStorm do a lot of really powerful and convenient things. It has been a nice compromise.

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.

How do you store them? Just backup into a dotfiles repo or what? I've been looking into dotfiles + gnu stow.

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've aliased ls to `alias ls='ls -GFhal'` to get around hidden dotfiles.

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.

+1 for this method! Good post. I originally learned about this through: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...

I use a Github repo, but I actually store it on Dropbox. I then symlink everything into place on a new computer.

Any change I make to a dotfile then shows up on any other machines.

http://github.com/napcs/dotfiles/

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.

https://github.com/garyharan/dotfiles

That's the post that inspired me to start cloning my config files from GitHub.

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.

0. https://github.com/thoughtbot/rcm

I use vcsh:

https://github.com/RichiH/vcsh

I have separate repos for SSH, Bash, VIM, and other stuff (like .inputrc).

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.

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 was searching for this earlier, I came across a HN post which someone from Atlassian write up really nicely: https://developer.atlassian.com/blog/2016/02/best-way-to-sto...

No extra tools (just git), no symlinks.

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.

Why is it weird? You created yours 10 years ago, great. For those of us who didn't it is a bit of a hassle.

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).

> 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"?

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.

This can be said about anything, though. You still have to develop muscle memory for shortcuts and menu paths in other applications.

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.

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.

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.

I get the feeling Emacs is where things like Atom and VS Code are looking for a lot of inspiration.

Unfortunately, they used bloated Electron framework.

Little over a year ago I began sketching out a native Mac OS editor, taking ideas from xiki, ia writer, emacs.

The core API was mostly fleshed out. I just got wrapped up in personal life stuff. Might have to take another look at that soon.

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.

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.

Recommend you checkout http://spacemacs.org/ It's an emacs with sane defaults and built around Evil (emacs vim plugin)

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.

No matter how much you tweak it, you will never even start to scratch an experience like Visual Studio. Vim is a fundamentally weaker platform.

Meh. I've used both and disagree. Visual Studio is a better IDE. Vim is a better text editor.

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].

[1]: https://marketplace.visualstudio.com/items?itemName=JaredPar...

[2]: https://marketplace.visualstudio.com/items?itemName=ZoltanKl...

The biggest issue is you're still tied to the real crappy windowing of VS, not the much better ones of vim or tmux.

VsVim is getting really good though, it even reads your vimrc these days.

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.

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.

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.

I disagree. Plugins breaking or interfering with other plugins is a regular thing.

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.

Wait, that doesn't sound like a problem with your vim config, it just sounds like you had a broken version of macvim.

I guess I must be doing something terribly wrong, because I can't relate to that at all.

Perhaps some kind of package manager that auto-updates plugins?

My packages are static and I only update when there's a good reason to do so.

Huh? my plugins never interfere with each other.

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 know, I'm "holding it wrong". I don't care who's "fault" it is, I just don't have the energy to try and figure it out.

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 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 mean, to each their own.

I've taken a month or two off from plugging Kakoune on HN because I was worried about becoming tiresome, but I can't resist mentioning it in this context. I used vim for 20 years, although I always preferred to stick with the default configuration. I switched to kak a couple of months ago, and I couldn't be happier. It's got great tmux integration, it automatically runs a server so you can connect multiple clients to one buffer, and it has a novel selection-oriented modal interface that's not just an attempt to mimic Vim.

I'd like to try Kak, a friend recently told me about it. But, I'm concerned about needing to relearn common commands. For instance, I believe that they mentioned that in Kak the Vim equivalent to `dw` is `wd`. I've got decades of use with Vi(m) under my belt, as well, and I am not too thrilled at the idea of having to unlearn/relearn common commands.

Having switched to Kak recently, I've found this painful since I sometimes SSH into machines with only vi installed and so have to switch back and forth between kak and vi; it's a real headache...and a real shame since kak's selection method is much nicer IMO

I find that I get irritated at vi / vim for not being as nice as kak, but vi is still useable. The hjkl keys still work, :w, :q! and so on are still the same. I, i, O, o, P, and p still do the same thing. Basic movement is almost the same except you don't get selection with your movements. I tend to fall back on this common subset when I'm using vi. Marks are different in kak, so I don't think to use those in vi. Same thing with ex commands. I'm more likely to use sed rather than messing around with vi's ex commands now.

The thing that confuses me most since the switch is vim's visual selection mode. I used to be a really heavy user of visual selection mode (V and v), but since selection is at the core of what kak does, vim's way of doing it seems really clunky now.

If I'm going to be spending more than half an hour on a machine, I'll probably end up taking a minute to build kak on it.

If I can SSH to a remote host I can use Emacs TRAMP mode to edit files or I can mount the remote machine file system with SSHFS and change the file locally.

I will never be forced to use vi! ^__^

The whole point of Kak is that it's a different editing paradigm, still modal and "text editing language" based, but in subject verb order rather than verb subject order. The idea is to give you more confidence as you type your commands by visually showing what they'll be applied to, instead of having to wait to see the result if you screw up.

If you're not interested in kak because of that paradigm change why are you interested in it at all?

I wonder if people whose language are SOV would find this configuration more natural than the vim order

It's painful, but on the plus side it's way outside of the uncanny valley, it's not like a vim clone. In practice I found that this meant going back to vim (kak didn't work for me) easy.

I think Kakoune is particularly interesting here because it integrates window splitting using tmux and a client-server model instead of re-implementing it which is what vim does. This is part of Kakoune's design philosophy: to be composable with other unix tools. Other examples of this are file browsing[1] and fuzzy finding[2] using ranger and fzf, or even just piping a selection to `fmt` to reformat a paragraph.

[1] https://github.com/mawww/kakoune/wiki/Ranger

[2] https://github.com/mawww/kakoune/wiki/Fuzzy-finder

I wish someone would build a VSCode-like shell around kak, in order to provide a good IDE experience. I keep thinking it should be possible using Qt, with plugins providing a GUI part in the form of a QML widget that gets embedded in the GUI, and possibly a daemon component that gets started and managed automatically by the shell. So e.g. you'd have a file browser widget on the left showing recently opened files etc. that spawns new tabs or opens existing ones when you click on the files. But you could also instead have a project widget or whatever. Basically I want someone to make a pluggable IDE, with a focus on adding graphical widgets for the purpose of richer interaction than plain terminal allows, but lighter and easier to extend than Eclipse, one which focuses on integrating with a specific editing component, in this case kak.

There's a guy working on a QML frontend for kak: https://github.com/doppioandante/kakoune-qml

Furthermore, Kakoune has a JSON-RPC user interface option that new UIs could be built around:

https://github.com/mawww/kakoune/blob/7482d117cc85523e840dff...

So it could happen if you wanted it bad enough!

Maybe. I've not experienced these same issues of "hard to maintain" Vim configs. However, just to learn, I downloaded VS code from the website right now. I extracted the archive and ran the executable.

Immediately, VS code took ~4 seconds to start. From there, I opened a text file and just started typing, and immediately my CPU usage spiked. From further examination, any kind of redrawing by VS code seems to cause the entire application to be redrawn on the CPU, meaning typing text in VS code causes ~30% CPU usage across most of my cores[0].

I'll pass.

[0] - http://i.xwl.me/2017-04-20-093624_4480x2096_scrot.png

I've used vim for a long time and simply don't bother with different configurations for different special cases. I also never bother with GUI versions. Just always use the terminal and only use plugins that are cross-platform.

This is a smart way to manage vim: terminal vim and a small number of the essential plugins. Clone ~/.vimrc and ~/.tmux.conf via GitHub. I haven't had any headaches doing it this way.

Have you considered splitting up your vim config into multiple files, particularly for the conditional stuff? It doesn't cut down on the size of configurations as a whole but it does make it a bit easier to approach.

I was in a similar situation. I had a lot of junk in my config files from when I started learning vim seriously, a lot of which I never really used. I've recently started to rebuild them to try and simplify things, cut out the unused but "neat" stuff I added over time, etc. Kind of the nuclear option, and largely a result of a failure to adequately comment my dotfiles.

That's the tradeoff with editors like emacs and vim, unfortunately. Pretty much everything can be customized or tweaked, but it's mostly on you to explicitly do so. Spacemacs/SpaceVim/SpaceNeovim are some impressive default experiences, but they achieve that through large, complex config files that make it difficult for beginners to parse. I was recently talking to a friend who was thinking of switching to vim, and to be honest, I was a bit unsure about recommending one of those configurations when asked for a good default. They have some fairly well-defined conventions of their own, and while that allows some pretty neat stuff, it struck me as limiting for the beginner. With a configuration that's so tightly written (not sure if that's the best way to put it), I kind of felt like I was setting them up to use vim, but not be vim users. They might make tweaks in the future, but they might never dig deeper to really customize it. Or worse yet, even realize they can beyond a sort of intellectual acknowledgement of the possibility.

At that point, they might as well be using Atom, ST, or another GUI editor.

Thanks. And I think SpaceVim is good for beginners.

Seems like this needs to provide your definitions for "better" or "high quality". I haven't tried VSCode yet, but I play with Atom on occasion just to see what the cool kids are doing. And I go back to emacs every time scratching my head that people still spend their lives on the mouse and arrow keys.

I just decided to dump Atom - I discovered that it gets very slow as file size increases (to the point where it could be described as "broken".) Makes me glad that I write most of my code in C and do most of my editing in vi.

I'm pretty new compared to most people, only have been writing code for about 4 years, with emacs and vim having been around much longer than I've even been alive. But I've always found vim to be just that an editor. I personally love it, it can do nearly anything related to editing. Atom/vscode seem like an attempt to make omni-IDE's for every language. Overall not sure what's better, it seems people compare tools such as intellij, which is aimed at a specific language (I'm only referring to java here, I know it has many other languages supported and tools built off of it), with other tools such as atom/vscode which are aimed at being almost a weaker in some aspects IDE allowing for it to be used for all work. Than this is also compared to vim, which is in my opinion the best editor, but it's just the best at that. If you want refactoring, or many other features vim isn't the best tool for the job, although you can always hack whatever in if you needed it. Can't really speak for emacs here though, as I've never learned more than the basics of it yet, it seems like a completely different beast. Overall, just always seems sorta silly to me how these tools are compared like you can't use them all, why not leave intellij open for its features, with vim open to do any quick editing needed for example? Seems like it's always "you can only have one or the other" with the way people describe it.

People have different workflows, and different desires for what they want out of their editor. For myself, I have just enough vim config to turn off compat mode and enable a few things. I think the only plugin I use is fugitive for git. I used to be a full blown IDE person, but I found that I really don't need all that stuff. Vim as a more featureful vi makes me very happy and requires no ongoing maintenance.

Neovim tries to improve defaults. My vimrc is 32 lines and contains no ifs and I'm reasonably happy with it. I don't use many plugins. The configuration is only as complicated as you make it to be. I suppose over the decades you used vim your vimrc accrued many layers of cruft. I wonder how your VSCode config will look like in 20 years.

> The configuration is only as complicated as you make it to be.

Sure, I understand that, and it's tricky maintaining a balance between simple configuration and features. My point is that with VSCode, there's just so much I get for free, with a very pleasant user experience. I still use vim when I need a quick editor in a terminal, but VSCode is my always-on go-to editor of choice for coding.

> I suppose over the decades you used vim your vimrc accrued many layers of cruft.

Yeah, I think I've got about 2 - 4 years of cruft (because I refactor and garbage collect a little bit every year.) But not 20. :-)

Still, it's a pain point that VSCode takes away. :-/

> Still, it's a pain point that VSCode takes away. :-/

Interesting. May I ask why you use that particular smiley then? If VS Code works better for you, isn't that a good thing?

However, I would also be interested if there's more to this for you than the configuration. VS Code is the nicest editor I'm allowed to use at work (because it's a MS product, some companies are really paranoid when it comes to other software) - but I never really warmed up to it. It feels very clunky to me when compared with Sublime Text or Neovim. Also the Vim plugins for it really haven't impressed me so far.

Am I missing something, or is this a pure matter of taste?

Can you share your 32 line config?

    execute pathogen#infect()
    syntax on
    filetype plugin indent on
    
    set list listchars=tab:>-,trail:-
    
    set ff=unix
    
    set autoread
    
    set number
    set relativenumber
    
    set linebreak
    set tabstop=2
    set shiftwidth=2
    set expandtab
    
    set ignorecase
    set smartcase
    set timeoutlen=1000 ttimeoutlen=0
    let $BASH_ENV = "~/.bash_aliases"
    
    color desert
    set cursorline
    augroup linehighlight
      autocmd!
      autocmd InsertEnter * set nocursorline
      autocmd InsertLeave * set cursorline
    augroup END
    :hi CursorLine cterm=NONE ctermbg=darkblue ctermfg=white
    :hi Normal ctermbg=black

Same here! I've been using both Vim (4 year) and Tmux (2 year) and I noticed I was actually spending more time configuring my text editor rather than just writing code. So I switched first to Atom and then to VSCode and I'm supper happy with the result.

What are you guys doing with your configurations?

I've been using vim since 2009 and tmux for the last 5 years. Initially, I had to figure out how things worked, and that took some time, but I never spent any time configuring it now except if I find a new plugin and figure out a new feature I'd like to add.

Nothing works out of the box, especially if you are trying to make two plugins work nicely with each other.

If you want IDE like features i.e Autocomplete than you have to spend days to make it work and even after that it doesn't work like other "GUI" editors.

+ Terminal interface is very limiting to have nice plugins...

I'm really glad I've switched to VSCode..

> Nothing works out of the box, especially if you are trying to make two plugins work nicely with each other.

Indeed, but it doesn't really matter since the default experience in VSCode or IntelliJ or Xcode or any other IDE or editor doesn't work for me out of the box either. I have to change things anyways, and I can't change VSCode or IntelliJ or Xcode to fit my liking, but I've been able to change tmux+vim to it, although it could be even better.

> If you want IDE like features i.e Autocomplete than you have to spend days to make it work and even after that it doesn't work like other "GUI" editors.

For stuff like Go, Rust, Elixir, Python and so on, it works fine with when just installing the default "brand" plugin. Taking python as an example: even though "intellisense" in vim is worse than in pycharm, the rest of pycharm is so much worse than tmux+vim. "Intellisense" not being 100% in tmux+vim is not a dealbreaker for me at all. I can get by without "intellisense". But pycharm is so much worse for everything else than "intellisense", from basic editing to opening files to running shell commands and everything else I use all the time, which is a deal-breaker for me. For something like iOS+Mac development where I feel like I can't work without proper "intellisense", I do use Xcode.

> + Terminal interface is very limiting to have nice plugins...

Indeed, but still, even though tmux+vim sucks on some points because it's text-based, it doesn't suck enough to not be usable, and all these other editors and IDEs like IntelliJ, xcode, netbeans, sublimetext, vscode, atom and so on complete sucks for all the important things I need, which is a deal-breaker.

> Indeed, but it doesn't really matter since the default experience in VSCode or IntelliJ or Xcode or any other IDE or editor doesn't work for me out of the box either. I have to change things anyways, and I can't change VSCode or IntelliJ or Xcode to fit my liking, but I've been able to change tmux+vim to it, although it could be even better.

I disagree. The default settings of Visual studio work perfectly fine for me. As an added advantage, I can use other developers in my companies workstations to show them something quickly if I need

> For stuff like Go, Rust, Elixir, Python and so on, it works fine with when just installing the default "brand" plugin.

and so on? I'm a C++ developer. Setting up C++ autocomplete is anything but straightforward in vim and emacs

> I disagree. The default settings of Visual studio work perfectly fine for me.

That's lucky for you, but unfortunately, it's not the case for me at all.

> As an added advantage, I can use other developers in my companies workstations to show them something quickly if I need

I might be using other peoples computers 10 hours a year, but I'm using my own maybe as much as 2200 hours a year. It doesn't seem logical to take the first scenario into account when deciding whether to customise ones setup or not, but it's indeed a nice bonus if ones optimal setup is the default one that every other developer is using too.

> and so on? I'm a C++ developer. Setting up C++ autocomplete is anything but straightforward in vim and emacs

I don't use C++ anymore, but 7 years back when I did, it worked good enough for my use case, and the problem with other IDEs and editors were the same back then as it is now, where they were actually hindering my work, which a less than perfect "intellisense" doesn't at all. YMMV.

Have you actually tried to get YouCompleteMe[1] to work for C/C++ autocomplete? It's a huge PIA. Autocomplete just works in VSCode and many other IDEs once you point them at the right directory.

https://github.com/Valloric/YouCompleteMe

I'm a front end web dev who decided to learn C (the other week actually). Took about 5 minutes to download and install YouCompleteMe.. What problems did you have?

The one problem I had was that I had to use the system version of clang as I'm using Arch.

Basically I am not able to compile my particular codebase in clang or gcc too easily since it's an embedded system. But many other IDEs have no problem inferring autocompletion without requiring compilation. YouCompleteMe itself was a bit of an issue as I have to develop in Windows and it's not quite as well supported.

Having to compile YCM for on an embedded system sounds like quite the corner case, and I can certainly see why you might have issues.

That said, there is a fair bit of built-in auto completion in vanilla vim (on par with VSC), and a few quick rebinds might be all you need. I would suggest checking it out.

    :help 24.3

(I wish it were indexed a bit better in the help files. :/ )

You should use a different completion plugin then. YCM is the only one that needs to be compiled. If you use regular vim, check out neocomplete, and if you use neovim, well, you should know about deoplete (it's kickass). Both of these pretty much work out of the box; they have accompanying clang sources (vim-clang or deoplete-clang) that feed the suggestions to neocomplete/deoplete.

Frankly, I would use neovim + deoplete. Modern, async, and a big user community right now (almost everyone with neovim runs deoplete).

Given that I am currently a windows user on visual studio, I'm not exactly sure how I would get started with neovim and deoplete. The instructions on deoplete [0] assume you're not running on windows, to start, and looking in the issues [1] It's not supported

[0] https://github.com/zchee/deoplete-clang [1] https://github.com/zchee/deoplete-clang/issues/57

I use YouCompleteMe for all my autocompleting needs (Python, Go, Rust, C) and it works quite well for me. My experience was that it was literally as easy as (copying the command straight from my shell history):

    ./install.py --clang-completer --gocode-completer --racer-completer

I use Emacs for C++ and I've tried a wide variety of auto complete packages, never really getting them to work properly. And the result is that Ive learned that I can be just as productive without auto complete as I was with it. In fact, I might even be more insightful into what I'm working on, because instead of relying on a pop-up menu for an API, I actually have to look at API documentation and properly learn it that way , which usually gives me much more knowledge about what I'm trying to do

Same exact experience here. Like, I could never get ES6 highlighting to work in Vim. Just flat out didn't work, so all non-ES5 code I write looks terrible. Could be a conflict with my theme or something else. I don't know, or care to do the work to figure it out.

I used Vim for a good 5 years. I still miss many things about it, but a shitty default UX is not one of them.

I feel ya. tmux+vim looks terrible compared to for example VSCode. Problem is that VSCode just works much worse (for me at least) for editing code, navigation, running commands and so on, and I'd rather have an ugly editor that works great, than the opposite.

For anyone else who happens by and has the same issue, vim had (has?) substandard syntax highlighting for javascript. Pulling in pangloss's vim-javascript (https://github.com/pangloss/vim-javascript) fixed that up for me. If you write JSX, you can pull in https://github.com/mxw/vim-jsx to get great highlighting for that too.

I of course use vim-javascript. This didn't fix the issue for me. An issue with the color scheme I use I suppose.

Yeah exactly... Main objective is just to write code, nothing more. No editor is perfect for me atm, VSCode eats my battery and it lacks some features but at least I'm only focused on writing code and having features that actually work...

>Nothing works out of the box

Usually because the box doesn't have coreutils, make and exctags installed. Bloated plugins are snakeoil, they push vim to the dark^WIDE side, where the battle is too Pyrrhic to win.

Or just install youcompleteme and get on with your work...

I tried switching to VSCode earlier this week and am really having a hard time with it. I'm coming from iterm/vim/tmux. The most painful part has been the lack of a hot key to bring up VSCode. Besides that, I've found that switching between open files in vim (which I use <leader> and buffer number for) is much easier than VSCode (ctrl + number).

edit: Just opened VSCode again and noticed one other major thing that has been driving me crazy. In vim I often have files open in different panes and then make one pane full size while editing. Can't do that with splits in VSCode as far as I know.

I did the same. I got fed up with constantly tweaking my Emacs config so I switched to VS Code. A month later I was back because VS Code was missing too many things I wanted and didn't really work the way I wanted it to.

So the way I feel about it now is, yes, it would be nice to not have to deal with these configurations. But so far, editors like this aren't as good as the ones that do require more complex configuration, at least in my opinion.

But as others have mentioned, it's not so bad. Once you get your config right you can mostly leave it alone.

If you'd like a consistently high-quality default user experience for emacs, check out Spacemacs![0] Especially since you're a Vim user. It's a distribution built around evil-mode with fantastic defaults.

[0] http://spacemacs.org/

The thing that prevents me from using VSCode, and I tried, is having to edit code on multiple systems. It's so nice to be able to have the exact same environment on my local system, remote production systems, test servers, VMs with crappy graphics. All I have to do to get my development environment set up on just about any Unix system is copy a few dot files.

Maybe there's a solution with SSH file systems or similar, but now I'm getting into the realm of configuration we were hoping to avoid, right?

For a while I was even using a Chromebook and doing most of my coding by SSHing to my much more powerful desktop.

> If there was one thing I could ask of Vim (or even emacs), it'd be a consistent high-quality default user experience.

FWIW I find both Prelude (https://github.com/bbatsov/prelude) and Spacemacs (http://spacemacs.org/) to offer pretty out-of-the-box experiences.

Same boat. I use Atom with vim keybindings now and I feel much more productive than when I rolled with straight vim + tmux. Great tools, but there are much better options these days.

Why does Atom feel more productive?

Because he/she never learned how to use vim

ZZZZZZZZZZZZING!

I am a huge fan of Vim. I've used it for quite a few years... but vim-mode-plus for Atom has made me very happy for the last month.

I found the Atom vim-keybinding plugins severely lacking in a lot of vim functionality that I use regularly.

I moved quickly back to tmux/vim.

Same here. Macros worked inconsistently, finding matching parens, and search/replace using registers just was off.

I use sublime, atom and VSCode every once in a while when pair programming but apart from intellisense/autocomplete I don't get a lot more value from the Vim alternatives.

On the same boat, recently switched to VSCode.

I wish I could have had some sort of true-integrated-vim-key-bindings, none of the vim-bindings plugins feel as productive, but editor as a whole has a lot more features for a lot less work.

In my humble opinion, emacs is much closer by default.

There are a couple of things which I think could make the default config simpler:

- Enable global-subword-mode by default.

- Enable delete-selection-mode by default.

With that, and maybe adding multiple-cursors to the default distribution (with a little bit more refinement) and I could use it out of the box. I would still probably set up colours, and I like my fonts really tiny, but those would be a matter of customization.

One other thing maybe is making M-x customize more discoverable. I think for a lot of users (including myself sometimes) it is sometimes simpler to search for an option by what you think it should be called, and select one of the known good values than it is to write the elisp expression for it.

Thjis is just what Vim and emacs die-hards won't recognize. This is the value of an IDE. The driving force behind these editors' popularity is bad developers.

I think that's a little harsh. What a lot of people (including myself) dislike about IDEs is that you lose a lot of tool composability, and to some extent you have to play by the IDE's rules. With a Vim + CLI setup, you get to define the optimal flow, but the tradeoff is maintainability.

For many, though, once you get your environment set up, it feels amazingly natural, more than an IDE could provide. It's more a matter of taste than anything.

Here is the key value provided by an IDE:

* Autocomplete. This deserves way more recognition than it gets. Having function signatures, documentation, overloads, types, available IN-LINE while you type saves so much work from programming and is essential to delivering correct code. If you want to be an effective programmer, this is a fundamental tool.

* Debugger. Easy breakpoints, conditional breakpoints, built-in profiling... Without these features, you will consistently produce inferior code.

I don't see how someone who calls themselves a serious programmer can throw away these exceptional tools.

VIM and other lightweights have their place, their place just isnt serious programming (by which I mean large software projects).

Whats more, VIM and similar tools make each step of the process, including incredibly simplke things like compiling and running your program, take exponentially longer and are similarly more xpensive to the programmer. I think most folks who don't believe this are simply in denial. VSCode delivers on these two features and is instantly an infinitely superior programming experience.

Its a cult.

If you really want I'm sure we could list out plenty of "serious programmers" that use vim.

Their existence doesn't surprise me, but they deserve less respect for making foolish choices.

An idiot savant is still an idiot.

I'll welcome any points made for VIM that acknowledge the immense value provided by IDEs, but if I had already seen such points I wouldn't even be posting here today.

Every argument I've seen for VIM systematically denies:

* That programming is hard work.

* That making life easier is a good thing.

Its just an extension of the masochism that permeates programming culture.

Your tone and absolutism is getting you down voted like crazy. You're placing the IDE experience on a pedastal and it's really not warranted. IDE's can have lots of problems, speaking as 15 year enterprise java developer. The primary problem is hiding complexity from the developer, which is obviously good and bad. For example, IDE's typically maintain an internal representation of a project, which can get out of sync in wierd ways. It's easy to spend multiple minutes rebuilding and refreshing "objects" (ie file and subprojects, and maven modules, etc) trying to get things back in sync. Here I'm speaking from years of fighting Eclipse, other Java IDE's like in IntelliJ are purportedly better in this regard. The fact remains, it provides an abstraction over the source files on disk, which are the source of truth.

Where vim and command line tools shine is giving the developer powerful tools to examine and manipulate projects, as they exist, on disk.

I personally believe there's a place for both. Vim and the cli are my secret weapon when it comes to comprehending, researching, and working with large, legacy, java enterprise applications. I only use an IDE when I'm actually editing java source files, which isn't very often. YMMV.

Yea you're right I've overstated my position. Don't really see how vim is useful for excploring a codebase.

Ever heard of ctags bud?

That isn't what the word idiot savant means it would be helpful in future discussions if you would learn the terms and idioms you intend to use. Idiot savants is a term for those who possess some interesting intellectual talent despite profound mental disability.

The individuals you are disparaging are merely talented developers working on useful projects they possess neither a surprising intellectual talent nor profound disability.

Despite your very superior opinion of yourself disagreeing with you doesn't imply mental disability.

You know why I don't like IDEs (especially bloated crap like RubyMine?) Because they're reasource hogs. They run slower. Vim + Tmux is as fast as you can think.

You're presenting opinions (strong ones) in the guise of facts, but you have no data nor even really anything to go by other than your experience/preference/anecdotes.

In general, the stronger your opinions the more you must work to ensure that they're communicated in as non-alienating a way as possible. This is one of the fundamental forces of communication/persuasion. As it stands, your current comment leans on hyperbole quite a bit, and uses unkind labels for groups of people who are quite likely to read your comment. As a result, I suspect your comment may not go over well.

Your opinion is well reasoned and helpful. I think its valuable in that others who actually want to communicate could learn and benefit from it but I think the party you are talking with is just a troll unfortunately.

I've noticed your trolling re: emacs & vim vs IDEs in the previous days (ie: mostly argumentless name calling), but I'll bite anyway.

Linus uses microEMACS, Guido uses emacs, Bjarne uses sam. The list goes on. What is your point exactly? That they are all fools & idiots? Or that the Linux, python & C++ projects do not qualify as serious programming?

Is it unfathomable that they know something you don't? Is it inconceivable that some people out there have a different yet valid opinion?

My personal experience with the few large codebases I've had to work on in the past is that IDEs would choke on them. If we wanted to get any work done that day we'd have to do it in a lighter code editor. As an added bonus, if we used vim or emacs we could now be as proficient remotely as we were locally.

re. Autocomplete - have a look at Vanilla vim's help files on Completion. Not the greatest, but still quite good and easily extensible (even without compiling in YouCompleteMe).

http://vimdoc.sourceforge.net/htmldoc/usr_24.html#24.3

And a debugger doesn't have to be built into an editor to be functional. PDB, GDB, PRY, your browser's built-in debugger... all are quite useful without being built-in to your code editor. As a bonus, all but the last can be easily accessed from your terminal (which, hey, you have multiple terminal windows readily available in tmux!).

Sorry, troll fed. My apologies.

Its amazing that you don't realize that its trivial to bind a single key to build your project in any editor under the sun. You could literally use ed and a shell script and bind a key on your desktop to fire off a build when you press a single button.

> * Autocomplete. This deserves way more recognition than it gets. Having function signatures, documentation, overloads, types, available IN-LINE while you type saves so much work from programming and is essential to delivering correct code. If you want to be an effective programmer, this is a fundamental tool.

Coding. This deserves way more recognition than it gets. Having function signatures, documentation, overloads, types available IN-YOUR HEAD while you type saves so much work from programming and is essential to delivering correct code. If you want to be an effective programmer, you need to stop relying only on autocompletion.

And as always.. have a nice day!

Autocomplete is obnoxious. I write Ruby primarily and if you need autocomplete for Ruby, you're probably doing it wrong.

I'm telling the same thing. Brain is required for coding not autocompletion. :)

For a debugger I usually run gdb in a terminal it initially had a pretty steep learning curve but I find it to be extremely powerful I mostly use it for analyzing core dumps rather than stepping through breakpoints. Being able to backtrace and step through stack frame by frame is really, really useful.

This.

I've only spent a few hours in GDB so far (mainly because my working environment doesn't let me), but once you've tried it, it's astonishing how little comfort most IDEs actually give you when compared to it.

I had to remotely debug C/C++ code on a very obscure ARM platform. Normal IDEs didn't get me anywhere. There are GDB wrappers like Nemiver that worked, but still were very clunky.

But with GDB in TUI mode, I just had to SSH in. If I have to learn two or three commands to use it, so be it.

Every time I have to do any of that remote debugging dance with any Microsoft product, I still long back for my GDB terminal. :-/

Reply on news.ycombinator.com