Tmux and Vim – better together | Hacker News Reader

Tmux and Vim – better together

blog.bugsnag.com

461 pointskiyanwang290 comments

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

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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. :-/

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

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 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/

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.

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

I use tmux and vim together as my dev environment for five years (used Sublime before) and I like to add another thought:

One huge advantage is that I can run the dev setup on a remote server which allows to keep the entire enviroment with all build tools and watchers live and persistent for weeks. You can do this on a local environment as well if you never shutdown the system or suspend only but it still feels different. Just an example: You worked weeks ago on a side-project and want to get in again for a small fix. Just to recall and open all relevant files, run the build tool and server plus tweaking the layout requires five minutes and usually you don't do it, you just want to fix one line and not think about the project setup. With tmux you go to the respective workplace with prefix+p (for previous) in case you kept the workplace still running. That's it. With a 1GB RAM VPS I can run many tmux workplaces/windows each with ~8 vim instances or other processes.

Further, I can develop on any of my notebooks/PCs/OSes with an ssh client installed, even on my phone. Btw, tmux and vim are perfect for phone keyboards, try it and it happens really frequently that you are on the go and want to try another idea/fix. Here, prefix+z for zooming into a pane is quite helpful.

And when I get a new computer my dev environment doesn't have to be setup again. I am still using the same remote server which survived three notebooks now.

And a (small) bonus: If you want to show coworkers your work in a browser (if it's a website) you give them just your static server IP without the need to ifconfig your current local dynamic IP before.

Running your dev environment remotely is a small thing but makes a huge difference in daily use.

> (btw tmux and vim are perfect for phone keyboards, try it yourself)

What terminal emulator do you use on your phone? Android, right?

Prompt on iOS and JuiceSSH on Android are very good.

That's what I have been doing for last couple years.

To make the experience even better, try replace ssh with Mosh

https://mosh.org/

Its perfect for mobile or desktop.

Also changing from bash to fish will make it even better.

I've found my flow with vim+i3+ranger

i3 is a window manager that can outcompete anything you can do with vim splits or a tool like tmux/screen. It's whole existence is based around putting windows in the right place at the right time.

Ranger is a vim-like ncurses file browser. I think it's genuinely one of the most underappreciated tools in programming. The ability to hjkl through your file system, with quick marks, with vim-style cut/paste, with visual mode, with about 20 other things that I use daily which just means that no other viewer comes remotely close.

My typical flow has between 4 and 12 terminals open, with the bulk being ranger->vim, which allows me to easily navigate complex project structures. The others are usually make, or htop, or some ssh.

I'll usually have a couple of web browsers open in another workspace as well. i3 tiling extends to all applications.

I use the same except for ranger. I'll have to check it out now.

How is i3 for a general purpose desktop? For coding it sounds great, but the same machine is used when I'm browsing the web or playing games or whatever.

I've been using awesomewm for a few years now, and while it's not i3 I believe it's close enough that I can answer that: A tiling wm is very viable for a general purpose desktop. It's also extra useful if you have a multi-monitor setup.

Applications that works in fullscreen (mpv, vlc, video games) requires you to set them fullscreen/floating, either yourself with a keybinding (Mod+f on awesome) or through the wm's config file. Some applications do not like tiling at all, some java gui apps from what I remember, but there are so few of them that I can't actually give you any example.

I say give it a shot, but beware: controlling your desktop entirely from your keyboard is addictive.

Keyboard is great sometimes, but do they have mouse control too? If I'm watching videos when I'm in bed I'm pretty mouse reliant, but if I'm coding then the more I can do on a keyboard the better

Some things can be done with the mouse: selecting a client, moving to another workspace, changing the layout, moving/resizing a floating (ie. not tiled) window

(awesome 4.x is more mouse friendly than awesome 3.5: in addition to the above, you can also change a few client modes with the mouse: float/tiled, maximize, stick (ie. display on all workspaces), on-top, close.)

Keyboard only: adding/removing columns/masters, moving a client to the master area, resize master area, move client to another workspace/screen.

Thanks, I'll put it on my ever growing list of things to try out.

For people wanting to try i3/awesomeWM/anotherTilingWM: Learn all the keyboard shortcuts, not just the basic ones. Spend some time on perfecting the configuration for you. Make keybindings that make sense to you.

Tip: Once you realize that you can make everything tabbed/stacked, your workflow becomes really fluent.

Example:

Workspace 1:

    Stacked (left):
        VIM - ASM / C
        terminal
    Stacked (right):
       ddd
       firefox (stackoverflow ftw)

I usually use :!command to run a command real quick from within vim, where I also have access to the current filename and contents.

A classic gem is ":w !diff % -" to see what I've changed since the last save.

That's what I've done for years too. I didn't know about the diff, but I love that - thank you.

I used to run more commands from vim, but now I personally find Ctrl-Z is usually more convenient for all the one-off commands. If I do run stuff from inside of vim, it's now usually ":w !" or ":r !" (or some custom command wrapper around those).

Oh! Ctrl-Z! I've been calling !zsh all these years, for quick shell access, and never thought of suspending vim.

Thanks for the nugget.

Put this in your zshrc, and Ctrl-Z will also resume the most recently suspended process. Really handy to just Ctrl-Z in and out of Vim.

  # Make Ctrl-z also resume background process
  fancy-ctrl-z () {
      if [[ $#BUFFER -eq 0 ]]; then
          BUFFER="fg"
          zle accept-line
      else
          zleush-input
          zle clear-screen
      fi
  }
  zle -N fancy-ctrl-z
  bindkey '^Z' fancy-ctrl-z

I don't really know zsh, but that looks like it should be

  zle flush-input

And as many other cool vim features, you can even extend that usage by combining it with other features. For instance, you can read the output of a command into the current buffer by ":r !command".

Neovim got a great builtin terminal emulator so I can just treat it like any other vim panes.

Last time I gave it a serious try I remember running in to a few oddities making me resort to keep using normal panes. Don't know if it's improved recently or if I were unlucky.

Normal panes are still nice in that they can be "far" from (n)vim; also sometimes I crash the editor and I wouldn't want my shells to vaporize.

This. I tried tmux but it required too much configuration, whereas Neovim just used my current terminal, already configured exactly the way I wanted it.

I had to make a few small tweaks, like making it easier to switch between VIM and terminal panes, but overall I'm very happy with the Neovim + terminal mode setup.

One of the attractions of tmux is that you can attach/detach sessions in arbitrary terminals, which is incredibly handy when working remotely.

Does Neovim provide this functionality?

Nope, abduco adds it pretty seemlessly without getting in the way, but unfortunately it doesn't seem to handle mouse events which I use occasionally with vim.

I've been using abduco and neovim as my dev environment for the past month or so and am very happy with the setup. I don't rely on mouse events so didn't notice that missing. Whenever I log in local or remote I start a new session or attach to the existing one with `abduco -A nvim nvim`.

It's a really pretty awesome set up, but when I am primarily in terminal mode and have a lot of scroll back I want to yank from I frequently will reach for my mouse. Lack of mouse support has stopped me from using abduco consistently.

Seems like some solid software other than that, I'm glad there's an option that interferes so minimally.

I'm not sure if Neovim directly provides this functionality, though Neovim can be run inside a tmux session, and tmux sessions can run inside the Neovim terminal.

How is the current status of Neovim? I think the last time I heard about was 3+ years ago.

It's great. I use it as my day to day. Sane defaults, I barely have anything in my vimrc.

The last time I looked at the terminal emulator built into Neovim the keybindings were terrible. What keys do you personally use for navigating in and out of TERMINAL buffers?

I am using `jk` to switch to normal mode, <space>H/J/K/L to move around. Didn't have any problem with that.

I use the bindings suggested in the Input section at https://neovim.io/doc/user/nvim_terminal_emulator.html. Took a little getting used to but now I quite like them.

Is neovim mature enough for day to day work?

Do you know any good beginners guide?

It's seamless. I've been using it for the past 6 months for almost all of my coding. The windows build is brand new and still has some problems, but assuming you're using *nix/mac, you won't have any issues.

Honestly the GitHub repo explains about everything. I check in on r/neovim, as the main contributor posts there often and helps people with problems/questions (I mostly just like reading about the new stuff their doing on the subreddit).

Nice article, I used tmux for a long time until I switched back to screen as it is default on most operating systems.

Dunno is it only me but I see a weird thing going on with "new" Vim community.

Everyone is starting to use it as a VSCode or Atom, trying to use hundreds plugins but most of them don't even know how to use tabs properly... I see most of this by new "neo" fans "you don't know how to make a thing in Vim? Download Neovim... or even Spacevim configuration." type of way. :)

Don't want to start a war here because every editor has it's own fans and I do not want to offend anybody either. But every one should learn to use vanilla version of their editor of choice before moving further.

Neovim is not what you think it is. It is a vanilla vim, it's just a fork of the codebase/community. It's not a package/distribution like Spacevim is.

I know what neovim is. I was talking about answering to all vim problems with "did you try neovim?"

Who really says that though? As a regular lurker on the vim/neovim subreddits and mailing lists, I've never seen anyone try to fix someone's issue in vim by telling them to get neovim (literally never). Because, in the end, they're going to end up with the same issue. You already know what neovim is....so why would switching solve anything? Say they don't know how to use tabs, omnicompletion...why would neovim be any different?

Now what you may see, to your point, is people pushing (one of the many versions of) Spacevim on those forums. And they are shat upon rather immediately. It does happen though. But that at least makes sense, because those programs make using vim "easier", therefore eliminating issues users may have.

But neovim? Certainly not. The only time that would be a suggestion for someone is if they want some of the features neovim has over stock vim (maybe they want saner defaults, for example, or don't like tmux and want an integrated terminal).

As I said before I have no problem with neovim. Yet, I'm reading HN from about 3 years and I see more and more posts like quoted above. Even in this thread was one or two - dunno where they are now.

My point here is only to learn first and extend further. Not throw yourself into high water with SpaceVim and than say how much vim or neovim is bloated.

SpaceVim help many people move to vim. as I know arroud me.

I think if someone is going to use something like SpaceVim, it would be best to start early and just learn that instead of vanilla vim. The initial cognitive load will be high for learning both anyways.

I personally do not have the patience for it even after giving it a try. But in my case, my 3yo laptop might just be too slow to handle all that bloat.

Many of them will be lost when editing something in vim on a completely clean remote server or anything other... Like how to explore files without NERDTree?

You can learn basic Vim commands in 30min with vimtutor. One thing to keep in mind is this: https://danielmiessler.com/study/vim/#language and this https://www.vi-improved.org/recommendations/

Nice article! I'm gonna introduce some of this in my configuration for sure!

I have a function in my .vimrc ( https://github.com/Morantron/dotfiles/blob/master/vimrc#L229 ) that allows me to send current vim selection to the adjacent tmux pane with vimux. This comes in very handy in REPLing sessions ( MySQL and the like ).

For copy pasting stuff ( like ids, urls, SHAs, etc ) I use https://github.com/morantron/tmux-fingers which is awesome and you should totally try it! ( </shameless-plug> )

Tmux is a great program, especially when trying to edit on a remote server. But I think it's worth pointing out that for most purposes, Tmux is basically just a Tiling Window Manager that only works on your terminals.

Tiling Window Managers are awesome, and I totally see why people who can't use one would choose to use Tmux, but if you have the option, I would totally recommend just going with the TWM and skipping Tmux.

I use multiple tmux sessions within my tiling wm (i3). A tmux sessions is for management of terminal contexts for a specific task/project. i3 is for managing the set of contexts (terminal, browser, etc) for a task/project in any given desktop and then multiple desktops for different tasks/projects. It's also nice for the sake of having another paste-buffer, but this is perhaps a little idiosyncratic.

Used Ion for years but finally just "upgraded" to fvwm2 and multiple tmux terminal windows. Reason? More often than not dozens of Unix hosts are being accessed through SSH rather than X. Tmux is always there, regardless of method of connection. Also, use the antique "nvi" (rather than Vim or Neovim) whenever possible. Same reason; it's always there, no tweaking.

If I find myself craving extra functionality I'm probably overthinking things and am in need of a vacation.

I use tmux within my tiling window manager: it manages my terminal, and the WM manages windows. It works great for me, because this way I only have a single terminal to worry about.

Prior to moving to a mac and using iTerm2, I did this very thing. But iTerm2 has good enough support for all of the same things, without some of the limitations imposed by tmux, that I find I don't need to use tmux anymore. Split windows, quick switching between panes, mouse support... it's all just there.

When I work remotely, I use the tmux integration provided by iTerm2 to provide more native windows, and it works well enough that I don't have to think about it most of the time.

If I were moving back to Windows or to a Linux development machine, I probably would go back to tmux in a single window. I'm just somewhat glad I don't have to right now.

I was a little bummed to see no mention of `slimux`. It's a fantastic way to execute commands in a real shell (another tmux pane) from the comfort of your ViM session. By combining this with say IPython running in the shell, it's a powerful way to do data analysis. I wrote an ebook on this kind of workflow at http://dvbuntu.github.io/compute/

I have been using vim since 1996. I really never started customizing things till 2005. I still keep things super minimal.

Amen.

This is great, I have a similar configuration with near to zero effort to setup thanks to vundle (vim) and tundle (tmux) plugin managers.

https://github.com/chilicuil/dotfiles/blob/master/.vimrc#L25...

https://github.com/chilicuil/dotfiles/blob/master/.tmux.conf...

One additional trick I often use is to look for inotify events in split tmux panes to compile/run tests on every save.

https://superuser.com/questions/181517/how-to-execute-a-comm...

Hmm. I use both vim (and vi since '93 or '92), and tmux, but maybe not with this type of workflow - mine is similar. For a shell, I use ConqueShell (and ConqueGDB when debugging) and have a vertical split bound to a leader (and you can use the output as a normal buffer - copy, paste, scroll, search using regex in normal, etc are some of the benefits). I've got shift+arrow bindings for navigating around buffers in splits, and alt+arrow for navigating around windows. As for running tests, I have autocmds that do bindings based on filetype for generic operations, and if there's a test I run often on a project, I just create a leader binding for it. If you're thinking about this type of workflow, give ConqueShell an eval. YMMV. edit: fzf seems to work a lot like CTRL-P.

I've been using this recently as well. ConqueGDB is almost perfect. I want to have a tab for development that is just files and a tab for debug that is a split with gdb and one file viewer for stepping & etc. But if I set breakpoints in my development tab the Conque buffer has to create a new split and show itself there. So I have to close it every time after I set breakpoints.

I had some problems with CounqueShell and ended up finding it easier to switch to a "real" shell using byobu.

How do you guys share session in TMUX beetween computers that there are not in the same local network?

ssh

I'd imagine it'd be pretty easy to do that with tmate, but I'm only ever sharing sessions on a LAN or VPN so I could be wrong.

Of course, you can always ssh in to a shared account.

I vpn into my home network when working from coffee shops etc and ssh into my workstation. It does require a semi descent connection but mosh helps mitigate a lot of issues with ssh and latency. Works pretty well and gives me descent battery life to boot since compilation/tests now run on the remote box.

I've also done it through a cheap digital ocean instance but compilation speeds are much worse and running tests takes longer, but it's a bit easier to set up and try out I guess.

mosh with ssh, very fast, resilient and excellent when roaming networks. Even the worst train network connections work decently with mosh.

https://mosh.org/

There's tmate: a tmux fork wich allow instant pairing without the hassle of ssh'in into the other computer and running a shared tmux. You can instant-run with the online service or install and use your own tmate server (BSD-licensed).

https://tmate.io/

Not sure if it is only at my Mac, but with the latest Mac OS + iTerm + TMUX + VIM, my clipboard doesn't work properly, even using the following setup on my tmux

bind-key -t vi-copy y copy-pipe "reattach-to-user-namespace pbcopy"

Anyone with the same problem?

No clue if you've done these steps, and I'm not on Mac OS at the moment (also I use Terminal.app), but:

In my main .tmux.conf I put:

  if-shell 'test "$(uname -s)" = Darwin' 'source-file ~/.tmux-osx.conf'

And then in .tmux-osx.conf I add:

  # https://robots.thoughtbot.com/tmux-copy-paste-on-os-x-a-better-future
  # To copy/paste on OSX just brew install the following
  # brew install reattach-to-user-namespace

  # Setup 'v' to begin selection as in Vim
  bind-key -t vi-copy v begin-selection
  bind-key -t vi-copy y copy-pipe "reattach-to-user-namespace pbcopy"

  # Update default binding of `Enter` to also use copy-pipe
  unbind -t vi-copy Enter
  bind-key -t vi-copy Enter copy-pipe "reattach-to-user-namespace pbcopy"

I only pointed out the separation of configs because it's kinda nice for my setup.

I had the same config, but I discovered what was missing. If you use zsh, you need to add this as well:

set-option -g default-command "reattach-to-user-namespace -l zsh"

Don't use TMUX, but other than that yes (presuming you mean that you can't copy to the clipboard buffers with * and +). I've not got round to fixing it yet; copying from iTerm works for single lines (for multiple you get line numbers too) and just doing pbcopy isn't too much effort otherwise.

I'm really a little disappointed how much this article is about using plugins and additional tools instead of learning to integrate both tools by oneself. At least vim is not a tool that gets better by plugins.

Vim absolutely gets better with plugins. ctrlp.vim, vim-tmux-navigator, vim-clang-format, ag.vim, vim-fugitive, supertab, vim-surround are all valuable plugins that I make use of every single day.

But you don't know what it stopped you from discovering about vim core that you solve your problems that way. And as shown in another comment in this thread, each problem you can solve with vim core you can combine with other features:

E.g., if you don't use a plugin for command execution and instead learn about ":!command" then you will at some point be able to automatically read the results from your command into the current buffer (":r !command"). This enables a complete set of features that you haven't even known before. For instance you won't ever have spelling errors in your IP addresses ever again, because you just read them with a ifconfig-grep-awk combo into wherever you want to paste it. If you also learn about creating your own vimcode functions you can make it even a hotkey to insert your current ip address at the cursor position.

All of that wouldn't be possible to discover if you used a plugin to execute shell commands from vim.

I still do those things you are talking about (really handy to read the output of find into the buffer when creating a new CMake file), but you are going to be hard-pressed to achieve something like :Gblame command from vim-fugitive or the funcitonality of ctrlp.vim without plugins.

Yes, you can't achieve the same thing without the plugins. You also can't achieve the interactive debuggers that IDEs have. But have you missed those? After some time I bet you've found other ways to debug your code that are just as handy, maybe not in all cases but therefore are even better in others. When I started to miss debuggers it forced me to really learn strace, logging frameworks of my favorite languages, dmesg, and journalctl filtering. It's still more work than setting up a breakpoint and tabbing through my code, but on the other hand I have it available as well, when I need to debug a wordpress plugin a contract worker wrote for my customer 10 years ago on a webserver that has none of my usual settings, plugins etc. In the end the pros and cons equal out I'd say.

And let's assume we can agree on that: Great plugins and great skill can on average be just as good. Why do I think that in vim plugins are the wrong course? Because everything in vim is based around skill. You can't even navigate efficiently without spending some time learning search, word/block navigation, etc. If one wants to achieve success with plugins I'd say it's much smarter to build your tools on a foundation that is created for plugins like emacs or an IDE.

I use tmux and vim often, but man my mind turns to mush reading about about either one of them. The biggest hassle I have is with copy-paste with tmux which I find ugly and can never remember. And then the method differs if you need to copy from tmux to another program that is not in tmux. Like for example just clicking on a URL in a tmux pane won't work (for me), nor have I figured out how to copy them so I can paste them into Firefox. And whenever I go read about it or ask it's like, 14 steps to glory and my mind is mush on step 4.

No, I don't think I have a brain injury.

I love TMux and Vim and I miss it when off my machine. Has anyone used TMux in the Creator's Edition of Windows 10? It is AWESOME. I need to get CMUS and Ranger working and I will be a happy camper.

I used it for a while but then I realized that ConEmu also supports split panes, and then i can just scroll/select the buffers by mouse instead of ctrl+b, [.

ConEmu really is an amazing piece of work. Quirky to configure (but hey, so it tmux), but truly amazing still :-)

If you like ConEmu try out cmdr http://cmder.net

> Cmder is a software package created out of pure frustration over the absence of nice console emulators on Windows. It is based on amazing software, and spiced up with the Monokai color scheme and a custom prompt layout, looking sexy from the start.

If you've already extensively customized ConEmu, Cmder is probably just going to annoy you. It's ConEmu in portable app mode with different defaults and some bundled tools.

You certainly can configure ConEmu but you can't make it into Cmdr.

Cmder is a bundle of ConEmu, configuration files, a tiny launcher that makes ConEmu's portable app mode easier to manage, and some provisioning stuff for the unix tools and cmd enhancements.

I'd use Cmder if I needed to carry a complete environment around on a USB stick, but it's not difficult to set up something similar for a single system manually with ConEmu.

You can scroll using mouse in tmux too. :set mouse

Not sure about selecting panes with mouse though

Selecting, resizing and scrolling panes as well as text selection works for me on Linux (urxvt) and macOS (iTerm), don't know about windows but I don't see why not. Using mouse on, works very seamless with the "new" mouse on setting these days.

Yes, you can select panes and windows with the mouse.

  $ cat ~/.tmux.conf 
  set -g default-terminal "tmux"
  bind-key -t vi-copy 'v' begin-selection
  bind-key -t vi-copy 'y' copy-selection
  set -g mouse on
  setw -g mode-keys vi
  
  set display-panes-time 3000 #3s

My two wishes:

- I wish mouse selecting text didn't select across multiple panes, or all of the blank space in a (zoomed) single pane. ("Anyone? Anyone?")

- I wish the tmux copy buffer ( ctl-b [ select yank ctl-b ] ) would copy into the system copy buffer ( ctl-v ).

I have wished those two wishes before. Haven't seen a solution.

Being a tmux+vim and acme user, I'd love to see some mouse integration when using tmux+vim: - right click on a file pattern, say some/path/to/file:line:column to open in the current vim session - middle click on some selection to execute in a new tmux pane

That would be a nice way to integrate with the surrounding environment without so many plugins, just simple programs that would run in a separate window.

Vim remote can help, neovim-remote might help even further.

What keyboards are everyone using for these setups? I find by the time you've got three layers (desktop, tmux, vim) the bindings are getting really complicated and inconsistent. Alt-tab might switch applications but then some lower programs use alt for a lot of things.

I'd love something configurable, like a dedicated WM key, a dedicated tmux key and a dedicated vim/app key.

I'm sure it's possible to setup manually, but it would take a lot of work.

Another idea is a tiling terminal program. I just started using Tilix.

https://github.com/gnunn1/tilix

It has panes, sessions, windows. Customizing is a lot easier if you're not already familiar with tmux. The one thing you get with tmux that's killer is if your shell dies (remote disconnect, you have to logout, etc) the processes in tmux keep running.

looks very good, been looking for a terminal that supports tiling and it has nice color theme built-in, thanks.

I like using :r ! <command> for running terminal commands.

What I liked the most about your article is that 'further reading' section at the bottom!

I use vim 7.4 and it segfaults atleast four-five times everyday. I suspect it's some plugin that is causing it to crash but I don't really know. Does it happen to anyone else too?

I have mapped Ctrl-C to ESC and I use it often. One specific instance I have seen vim crash is when the cursor is at np.inf and I press Ctrl-C.

Vim has never crashed for me. And I've been using it almost exclusively for almost ten years.

I don't use any plugins though. I haven't found a single usable plugin. They are terrible hacks. I figure vim must have an API that's difficult to integrate (it's too general a text editor. Look at the amount of built-in settings that hardly play nice with each other).

I agree. Vim is solid as a rock. I've been using it for about 10 years and I saw it crash 2 times. On the other hand, I had to use Atom for 2 weeks and it crashed on me exactly 6 times.

Have you tried upgrading to a non-ancient vim?

Or, to neovim.

Actually, neovim is somewhat more prone to crashing than traditional vim, in my experience

It's 6 months old at most. Their distro probably doesn't even have vim 8 yet, ubuntu 16.10 doesn't.

I had this problem about a month ago until I upgraded to Vim 8 - not had a segfault since.

It's also worth spring-cleaning your config/plugin setups.

Either you have a plugin that's wreaking havoc, or you have something weird in your setup, because a stable Vim version crashing is not something I've seen often.

I've shyed away from using tmux and Vim. For some reason, when I use tmux and Vim, if I 'copy' a snippet of text (using my mouse/cursor higlight -> right-click -> copy) it treats all of the empty space a actual "space" characters when I 'paste'. Why does it do this?

Because that's how you create a vertical split. Maybe it could choose not to do that when there is no pane to the right of the current pane. But maybe the heuristics on that are hard.

Expecting terminal programs to interact sanely with mouse gestures is somewhat futile. If I need to paste something from a vim buffer into a graphical application, I use :'<,'>!xsel -bi to copy the text. If I were doing it more often, I would probably add a keybinding to streamline the process, and solve minor annoyances like having to undo to get the copied lines back. Maybe there is a good plugin for clipboard integration?

https://github.com/wincent/clipper is what i have been using for clipboard integration. It is useful for remote server clipboard syncing too.

You could use "y (and/or "+y, depending on your X clipboard setup) to yank to your clipboard. Similarly, "p paste from it.

HN garbled your "* y, but I understood anyway. Thanks!

I always forgot which of + and * works and end up having to try both. I think I looked up the difference once, but I didn't retain the information.

Same, I don't use tmux with vim for exactly the reasons you gave.

Instead I use i3 to split screens, etc. much better imo.

exactly a tiling window manager. though i do use a multiplexer in tty if i need to work in that environment.

Problem is attaching the session on a remote machine, this is the main reason I've gone back to mainly using tmux in fullscreen workspaces instead of relying on a tiling window manager.

Still often use tiling though to tile a browser with a terminal or two browsers.

I just maintain multiple SSH connections.

I believe this is because vim manages drawing the entire screen, rather than depending on its terminal emulator to wrap lines, etc. This may be dependent upon configuration, and the setting `t_ut` (which is the background clearing color).

Anyway, using tmux for selection in vim is a bad idea. You can give vim mouse support by `set mouse=a`, which will prevent tmux from capturing selection and scrollback control if you like. Achieving parity between vim, system, and tmux clipboard (and for bonus points, across a network) is left as a "fun" exercise.

Because when you are selecting, that usually means that you let the terminal select from the contents of the terminal buffer. And vim is out of the game. It may for example be that your vim draws actual spaces to fill each line for rendering on the terminal. What you describe doesn't happen for me on xterm+vim and neither on xterm+tmux+vim, but it may well happen on a another terminal or with different vim settings.

You can let vim catch the mouse clicks / drags and have it manage you X11 clipboard (start looking at vim help for :set mouse=...). Personally I prefer to not have vim mess with my mouse and X11.

I think it's better to just use vim's horizontal selection ("visual line", Shift+v) and use yank (y key) or filter it into an extern command like "xlip -i -selection clipboard" to copy the highlighted text into the clipboard.

You can also just yank directly to the system clipboard: "+y

I don't know if this will solve your problem, but you can try

  set clipboard=unnamedplus

Then all yanking and deleting will put the yanked or deleted text in the X11 clipboard, from whence you can paste it in other applications, including terminals. For more information try

   help registers

I use this all the time, and find it essential (no mouse required).

I just tried this on my Mac with tmux, vim, and textedit (with a normal text file) and didn't run into this problem. This is with vim 7.4 and tmux 2.1.

The outmost program must do the copy&paste. So if the outmost program is tmux, then use tmux copy&paste.

https://awhan.wordpress.com/2010/06/20/copy-paste-in-tmux/

I'm just learning all of this, but since it's a suggestion from some smart people I bet, just like in vim, that you can do a lot more once you've overcome the first pain of using it correctly.

i used to use tmux but when i migrated to neovim i started using its built in terminal for multiplexing instead.

Interesting, I suppose neovim much like emacs is turning more and more into an entire OS/environment for some users nowadays using it as a windowmanager like that.

Lots of good advice, Vimux was the killer for me I think. I have a common workflow of edit -> run -> edit and that will make that workflow seamless.

I also tried out vim-arpeggio but kept seeing "Arpeggio is not defined". Looks like the project hasn't been updated for a while.

On my mac I used tmux and vim for years. However, only after building a little arch linux box did I realize I actually wanted a tiling window manager and an ide all along.

At one point I was using a tiling WM and tmux. But between the WM, tmux and vim windows.. well, I don't really need 3 layers of tiling, so I got rid of tmux.

I'm sort of stuck in IDE Mode now. Been using IntelliJ for a few years with a vim emulator in it. It's alright but I miss this cool stuff too.

I wish tmux could document their line protocol. Currently only iTerm is using that to integrate with tmux and no one else is doing it.

Terminator devs are working on the same kind of integration [1]. You can already attach to a running tmux session and Terminator will pick up the layout and create the splits and tabs accordingly. It has some rendering issues if you are using zsh and/ or fzf but otherwise great to see the progress.

[1]: https://bugs.launchpad.net/terminator/+bug/1301605

Mouse integration has always been the blocker for me with tmux. Any good solutions out there yet?

What issue do you have? I use tmux on iTerm on macs and it works just fine. Maybe you have an issue with your tmux conf?

Just set the following configs at your .tmux.conf

# Enable mouse set -g mouse on

# Sane scrolling set -g terminal-overrides 'xterm*:smcup@:rmcup@'

Mouse works perfectly fine (at least in macOs), you can even resize vim panes and tmux panes using the mouse.

They fixed the mouse integration about a year ago, I remember it being a bit of a hassle before that.

I use tmux window instead of splits.

bind-key -n C-t new-window

bind-key -n C-w kill-window

bind-key -n C-n next-window

Nice post, I want improve tmux layer in SpaceVim. I think it is best editor for developers.

https://github.com/SpaceVim/SpaceVim

You wouldn't happen to be an author, would you? Could that maybe be why you believe it is "the best editor for developers"?

Good article. I like the colors you chose for tmux and vim

Anyone know what shell colour scheme they are using?

I want to know it too

https://github.com/gregsexton/Muon :)

Awesome. Do you also know what they are using for the shell? Seems to be something a bit different from that theme.

It looks like Atom but Im not sure, you can see more of them here: https://github.com/lysyi3m/osx-terminal-themes

I think you have to be a fool to use anything short of a full IDE unless you have no choice.

Disappointed in Bugsnag for covering such trodden trails for a HN front page grab. Content marketing should have something to do with your business. There are hundreds of blog posts describing this exact setup.

What's your indication that this was submitted by bugsnag rather than by an HN member? If you think this or any other submission is inappropriate for HN, please flag it and move on.

I'm disappointed that they wrote it, and whether or not they submitted it to HN it's still a blatant traffic grab. It has zero to do with error reporting.

Not once does the article mention Bugsnag or try to market their product. Who is to stop an enthusiastic engineer from sharing a workflow they find useful. The article has great content and powerful visuals to help convey their point. I'm happy to see companies not try to influence authors to plug their product in their blog posts.

Then it goes on their personal blog.

Looks like what he really needs/wants is an IDE.

I use tmux and vim too. The problem is no IDE (or editor) comes near tmux+vim for me. If they did, I wouldn't be using tmux+vim since it's an awful experience living inside a text-based window-manager like that.

Looks like he has one that fits his needs nicely with the bash terminal.

What I most time miss in an IDE is tight terminal integration, I find myself often redirecting buffer contents between panes, terminal pipelines and composing microprograms on the fly to enhance my workflow.

In fact, if you are not on Windows your OS already _IS_ an IDE. An OS is software, so it also needs to be developed. Therefore it was natural for OS developers to create their OS in a fashion that enables development. Apple and Microsoft are the only exceptions, and Apple somewhat backtracked on that path to enable developers as well.

Some easy things are usually much faster to learn in a traditional IDE, since it has GUI. But that often leaves people less able to continue development _OF_ their development environment. If you want the full power or understand how stuff works underneath you better use an OS that works as IDE, e.g. Linux.

>os is an ide

It went nice for me with mingw/msys and selected tools for few years, but modern windows (>=vista) ugliness and death of native windows gtk distribution completely dimmed it. Msys2 may be a solution, but what a mess it is for non-packaging people. Since yesterday night I'm more than happy with mint/xfce laptop again.

I really don't need anything windows-specific, except few time-stealing games.

Reply on news.ycombinator.com