11 ms·
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-de
by zeroxfe 10y ago
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.)
- joonoro 10y agoI 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.
- adrianN 10y agoNeovim 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.
- zeroxfe 10y ago> 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. :-/
- btschaegg 10y ago> 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?
- RomanPushkin 10y agoCan you share your 32 line config?
- adrianN 10y agoexecute 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
- ika 10y agoSame 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.
- fredsir 10y agoWhat 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.
- ika 10y agoNothing 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..
- fredsir 10y ago> 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.
- juandazapata 10y agoWeird. 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.
- rublev 10y agoHow do you store them? Just backup into a dotfiles repo or what? I've been looking into dotfiles + gnu stow.
- falcolas 10y agoI 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.
- rublev 10y agoI've aliased ls to `alias ls='ls -GFhal'` to get around hidden dotfiles.
- juandazapata 10y agoI use a Github repo + gnu stow. I wrote a little post about it (http://juanda.me/managing-your-dotfiles-with-gnu-stow 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.
- dylanz 10y ago+1 for this method! Good post. I originally learned about this through: http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to...
- dwc 10y agoPeople 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.
- ryanswapp 10y agoSame 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.
- artursapek 10y agoWhy does Atom feel more productive?
- matzy 10y agoBecause he/she never learned how to use vim
- artursapek 10y agoZZZZZZZZZZZZING!
- nobleach 10y agoI 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.
- mod 10y agoI 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.
- c0achmcguirk 10y agoSame 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.
- sevensor 10y agoI'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.
- scruple 10y agoI'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.
- brynedwards 10y agoHaving 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
- sevensor 10y agoI 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.
- Bluestrike2 10y agoHave 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.
- wsdjeg 10y agoThanks. And I think SpaceVim is good for beginners.
- nilkn 10y agoI'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.
- wyclif 10y agoThis 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.
- ajross 10y agoSeems 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.
- MrTonyD 10y agoI 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.
- apcsniperz 10y agoI'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.
- Periodic 10y agoThe 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.
- molloy 10y agoIf 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/ http://spacemacs.org/
- city41 10y agoI'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.
- tomsthumb 10y agoThe 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.
- city41 10y agoThat's what this project is working on: https://github.com/carlosdcastillo/vim-mode 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/ 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.
- jdc0589 10y agothat's exactly how limetext approached it. one back end, multiple frontends. I think that project is dead-ish though
- ruleabidinguser 10y agoThjis 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.
- news_to_me 10y agoI 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.
- ruleabidinguser 10y agoHere 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.
- mxvzr 10y agoI'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.
- lelandbatey 10y agoMaybe. 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 http://i.xwl.me/2017-04-20-093624_4480x2096_scrot.png
- ptr_void 10y agoOn 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.
- microcolonel 10y agoIn 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.
- wtbob 10y ago> 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 https://github.com/bbatsov/prelude) and Spacemacs (http://spacemacs.org/ http://spacemacs.org/) to offer pretty out-of-the-box experiences.