In the conclusion the author says "It may not replace an IDE if you’re coding in Java or C++, especially if you’re using Frameworks and auto-complete is helping you."
You don't have to make that choice and can have "the best of both worlds": For the last few years I've not been using Vim itself, but Vim bindings in VSCode and Intellj. I enjoy the trade-off of this this approach because it
- is trivial to set up (in stark contrast to configuring a untouched Vim/Nvim install from the ground up)
- gives me simple access to powerful extensions
- allows me to use modern editor/IDE features (find usage, refactor) without forgoing "the essence of Vim", rapid code editing through the combination of motions & commands
To me, the key commands are only half of why I stay on Vim, and the half I'd be most willing to give up. It's as much about living on the command line and 10-15 years of having Unix a ctrl+z or tmux split-pane away.
I'd like to have some of the refactoring facilities you find in IDEs, but I'd prefer to have them as separate tools, commands you run, rather than moving everything into one window.
Out of interest, how do you go about debugging code when you live on the command line? In an editor you have nice features like a visualisation of the call stack, and the ability to set watches and conditional breakpoints. Are there vim equivalents, or do you live without?
Not OP, but having a good debug log is invaluable. I prefer it to using an IDE debugger. It's rare I need to debug in an IDE, because I can read my logs and see what went wrong and where. Then all I need to do is read the code to find the faulty logic.
I just use either gdb's tui, or the new gdb integration in vim 8, along with a few custom pretty printers for types, but you'd have to write those no matter what debugger you used. One difference is that I do not debug in the same editor instance I write code in - it's possible, but I don't like having my editor switching state. It is possibly slightly suboptimal as far as debugger interfaces go, and perhaps using Emacs with its gdb integration would be better, but I haven't felt the need to do so yet. The backtrace, variable values, local variables, thread list, etc. etc. are all there, just not in floating windows, but behind commands you run to call them when you need them. Since it's all text, you can just copy and paste to a temp buffer if you want to take notes. I have never felt limited in my capabilities to debug per se, but a modern reinvention of DDD would be appreciated. Also since everything is text, entering and recording any information is dead simple.
An aside, as another poster noted - Vim's editing keys are the first thing I'd give up for a better Vim. I've tried Vim mode in VS and it's not Vim. Yes, you move with hjkl, but the editing keys and the entire rest of the IDE are two entirely separate worlds. E.g. I can't record a macro that jumps to a symbol definition as part of its execution. In Vim the entire experience is integrated and there is no separation between "editing keys" and "navigation keys", etc. At its core, Vim is a parser for a sequence of keystrokes where each runs a command. Any command can be bound to any keystroke or sequence of keystrokes. The entire system is based on a few basic principles that apply equally across all keystrokes.
Just embedding a Vim editing mode in your IDE is not at all the same as the real thing. It is still better, especially if you need to limit your finger movements due to RSI or other issues, but it doesn't recreate the reason for which I use Vim. To replace Vim, you'll need to do the inverse - rather than have the IDE as a shell and a Vim mode embedded in it, have a Vim interface as the shell and IDE functionality embedded in it.
I imagine you use something like GDB which has different commands to do that stuff. For example quick Google search reveals [this](http://www.it.uc3m.es/pbasanta/asng/course_notes/debugger_co...) for conditional breakpoints (haven't used a command line debugger in forever tho)
Depends on the environment, but a lot of print/exception-based debugging as you'd expect, or use REPLs when they're available. I do a lot of web work currently and occasionally use the debugger in Firefox. I have also used GDB in other contexts.
I don't really feel like I'm too lacking in this department, but maybe the things I do aren't too complex.
It depends on what you're debugging. There are plugins for a variety of languages and if you're a web dev, none of that matters since debugging with the browsers dev tools is pretty comfortable.
gdb for C, Firefox dev tools for JS, ipdb for Python. The Firefox dev tools are probably the weakest of these, but the other two handle everything you mention just fine.
For any Eclipse users here (can't speak to any other IDE), many of Eclipse's features can be invoked headlessly. For a year or so I did most of my Java dev in Vim because I had to work on a remote server, and Eclipse was unusably slow over X11 streaming, but I still had a keybinding that triggered the Eclipse formatter on my open files. I'm sure many other options would work, though I'm sure some just won't. I just used ctags for autocompletion, and I was happy enough with it. Only works if you already have a good idea of what's available, though.
> It's as much about living on the command line and 10-15 years of having Unix a ctrl+z or tmux split-pane away.
I press F12 in my IDE and I get dropped into a terminal or I can just open XTerm independently... I don't follow how this is a valid argument against IDE's.
I wasn't really providing advice on what the objectively optimal setup (lol) is, I was just explaining how I work. My point was just that vim keybindings are not a very big part of why I like this environment.
Vim has really good language server integration via multiple competing plugins (vim-lsp, ale, coc.vim, neovim). You can use the same language servers from VSCode, which give you autocomplete, code-formatting, refactoring, etc.
Not having to leave the terminal and vim's responsiveness are still a big pluses for me.
My experience with language servers in VSCode has been less than stellar (looking at you Golang integration).
I just haven't found anything as responsive as IntelliJ's custom embedded autocomplete/code-formatting/refactoring capabilities yet... everything else is just inferior feeling.
I never had much success in setting autocompletion in Vim. Jumping to symbols somewhat works but since the editor itself is not build-aware it always gets thing like include paths wrong. Maybe with editorconfig.json or something it would work better, but in the end I found completion in dedicated IDEs always much better.
Language servers are supposed to mitigate that - they're supposed to be build aware and know all about include paths etc. For the C family this is usually done by having CMake write out a compile_commands.json file as part of its configure step, which is then picked up by the language server. Other languages should have their own methods. I still use build-unaware indexing, i.e. ctags, because it's simpler, faster and lets me look up things that aren't part of the current build configuration without having to switch builds.
> - is trivial to set up (in stark contrast to configuring a untouched Vim/Nvim install from the ground up)
1. Part of the joy of vim is not configuring it. A ton of the plugins out there exist because the creators didn't know that a feature already existed in vim, and many of them break existing keybindings. Beyond a few small configurations, I use vim as my daily editor largely untouched. A big upside to this is that I can log on to almost any server and have an editor that is pretty close to what I use anyway.
2. My configuration process is (assume you're in ~):
This works fine for pretty complicated configurations, but if there's something that can't be configured in a dotfile, I imagine it wouldn't be hard to add a ./configure script that does the rest.
> A big upside to this is that I can log on to almost any server and have an editor that is pretty close to what I use anyway.
Maybe for sysadmins that are always doing a ton of text editing on remote servers, but I haven't run into this. Even when I do work on servers though I don't have any problems using vanilla VIM even though my workstation has 70 plugins. I do take care not to override any of the base keybindings though. If you are overriding core bindings you deserve what you get hehe.
I generally find that whenever someone points out that a feature that a plugin implements is already present in vim, the vim native feature has atrocious UX. It feels like a personality thing, it just seems like a lot of vim users don't care very much about decent UX.
If you're talking about traditional UX values like intuitiveness, sure, vim UX is terrible.
But vim features tend to do very simple things, which are composable into very powerful mini programs in a lot of contexts. There's a sort of "discoverability" to them as well, in that if a key does something in one mode, it likely does something intuitively similar in another mode. All this adds up over time. I've got about 9 years using vim every day now, and the combined learning over that time has added up in a way that disposable learning like "how to use the X flavor-of-the-week plugin" would not have.
Another thing here is that the UX improvement of most plugins is only surface-level. vim features tend to be very simple, which means that when you understand it, you understand it. But vim users with a lot of plugins rarely understand what is actually going on when they use a plugin feature, because the features do too much. This means that they can't really use those features in, for example, macros, which loses you a lot of the editor's power.
Vim binds are definitely great but using terminal Vim is more than just the mappings.
Everyone uses Vim differently but I tend to combo it with tmux. For example I often have 8+ active tmux sessions (1 for each freelance contract I'm working on + personal stuff). Each tmux session has 1 or more Vim instances running, so switching between each session is 1 key stroke away. It's effortless to jump between them and the state of those sessions are always around (even persisting across reboots with tmux-resurrect). It also takes up close to no resources (a few megabytes per Vim instance).
other than a notepad replacement, I don't really use Vim.
But I do use VsVim in Visual Studio and also have a guide on how to do that with R#, I use Vim emulation in all the Jetbrains products as it's really well done, also in VSCode, Vimium in all my browsers. Also use AutoHotKey to add Vimish type navigation to windows controls.
Vimium is available for Firefox [1]. There are actually quite a few others too: Saka-key, Surfingkeys, Vim-Vixen (as a sibling has mentioned), VVimpulation and, last-but-most-janky, Tridactyl [2]. It'd be remiss of me not to mention Qutebrowser which is a standalone affair.
Thanks so much for working on Tridactyl, it significantly improves my quality of life and saves my wrists! I'll be sure to donate once I have a full time income.
Why do you say it's janky? I love it and it feels pretty polished!
The only issue I have is when selecting the HN upvote/downvote arrow links with 'f' the letter hints overlap :D
- `gi` doesn't work reliably on enough pages for it to be useful, ditto for `g;`.
- we outright break a handful of websites unless you `seturl [url] noiframe true`
- our mini-language is dreadfully inconsistent (e.g. `winopen -private` but also `hint -qb`). Corollary: composite commands steal semi-colons from JavaScript.
- most importantly, entering stuff into the command line is not a pleasant experience compared to our competitors due to lag and various things that block input but shouldn't (this is worse on Windows and generally gets worse the bigger and older your Firefox profile is)
I still like it, though. I'm glad you do too!
For your problem, I'd suggest making site specific binds: e.g. `bindurl news.ycombinator.com ;u hint -Jc [title="upvote"]` and, as a guess, `bindurl news.ycombinator.com ;d hint -Jc [title="downvote"]`, but I'm not cool enough to have downvote buttons so I don't actually know if that last one will work.
The best thing about Qutebrowser is that it's not only standalone but also it's 100% controllable via keyboard.
This is simply not possible with other browsers where the UI outside the actual website was only designed with a mouse cursor in mind. And that contradicts the idea of not constantly needing to switch to the mouse and back.
I agree, but I don't really use Tridactyl to replace the mouse - I use it for operations that would otherwise not be easy or possible (e.g. `b` and `B` to search through the titles of open tabs) or a favourite of mine, cloning a repository from Git{Hub,Lab} and opening a terminal in that folder.
Some of this lack of concern for using the cursor is probably because all of the keyboards I use have trackpoints.
I've tried the IntelliJ vim plugin and it was lacking some features that I use regularly (I forget exactly what at the moment. Registers? the 'q:' menu? folds? quite a few plugins I now can't live without? (surround)).
Another key thing is the responsiveness. Vim is just more responsive (or it feels that way to me, you may have different experiences).
I am developing Java using vim + tmux at work and it for certain took a lot of time to get tweaked how I want it to be, and there are some things I've had to give up: debugging is a big one (but that's what log messages are for!), but I 've managed to cover quite some ground:
I wrote a plugin to automatically add import statements based on dependencies you have listed in your build.gradle
Yeah I know the image (ooo that guy thinks he's sooo l33t because he uses vim and the command-line all the time... doesn't even need intellij installed!), but I know my setup works for me and it allows me to work as fast, if not faster than my peers and get. crap. done.
To each their own - I make sure that new engineers I'm on-boarding have tools they need to get work done and don't fall prey to some tool-cult.
I like this approach and used it for some time but I ended up going in the other direction ultimately and configured neovim to be a customized IDE. The setup isn't for the faint of heart but I find tinkering with it quite relaxing and enjoyable.
I use both vim and vscode, and I find that the vim keybindings in vscode are lacking. I particularly run into problems with substitutions, for example in vim I can do :sno... when I want to change brackets or something whereas that doesn't exist in vscode. I then have to use the native find and replace menu stuff which breaks the flow.
In a mathematical/academic sense, we usually use 'trivial' for a thing that's 'easily' solved. For instance 'X is a trivial consequence of Y' or 'proof of this is trivial'.
I do the same, however, there's one thing annoying and that is the lack of macros for these ported vim bindings. `norm` command also doesn't work for intellij (along with many other more obscure vim commands)
I tried, but I missed a lot of thinks like being able to click a random line instead of down down down down. Or selections. Commands are good but I pretty much just use find and replace in vim.
You don't have to click down multiple times. If you want to go somewhere specific there are too many ways to list tbh but they're all faster than arrow keys or mouse clicks. I'm a big fan of the EasyMotion https://github.com/easymotion/vim-easymotion approach myself but the built-in search functionality + tag navigation is also good.
It's also a great way to learn Vim in the first place. One motion at a time, without getting stuck when you can't recall it, or slowed down when you're in the flow.
I completely agree. I still keep vim nearby, as it’s everywhere, fast on large data files, and has some power tools for editing plain text that «code editors» just don’t have.
>To navigate a file on Vim, use the letters h,j,k, and l.These commands are called motions, as they move the cursor. The keys h and l will move your cursor horizontally (one character at a time), while j and k move vertically (one line at a time). If you put your hand on them, the layout sorta makes sense.
The way the author explains it above (mechanical) is the way I was initially taught over 20 years ago. However, it wasn't effective for my learning style because it felt random and incoherent. So _why_ does 'h' key move left? And _why_ do I have to press 'i' for "insert" mode when I didn't have to do that in Notepad/MSWord? My UNIX instructor couldn't answer those questions. He just said, "I dunno, it's just the way it is." As a sysadmin, I memorized it but it was a very unsatisfying way to learn vi.
My brain is most receptive to learning when it knows the underlying philosophy of why things are designed the way they are. Previous comment with some links.[0]
Once one knows the design intentions behind vi, the learning feels much less random.
The other problem is that he doesn't have a sample.txt file for people to download, so he's asking them to open a blank file, then he teaches them how to move around (but there is no text), and only after all that does he start teaching them how to actually insert text.
Emphatically, this. I struggled to really understand and become comfortable with vim until I actually (1) completed the tutorial (vimtutor), (2) read the manual (:help user-manual), and (3) learned to use :help. If I would have just read the splash screen instead of browsing intro/intermediate-level vim articles online, I would have saved a lot of time in the long run.
As an aside, vim has really had a positive impact on my life (no hyperbole). It's the only editor I've ever used where I can regularly reach a state of "flow" during my day. I highly recommend giving it a try beyond learning hjkl, if you haven't already.
I used Spacemacs and then Emacs + Evil for a while.
My biggest problem is that it is SLOW.
Emacs, even without the Spacemacs bloat, would regularly freeze up on me or feel slow and a bit sluggish.
My main reason for sticking with (neo)vim over Jetrains IDEs or VS Code is the incredible responsiveness. Thanks to Coc et al we now get awesome IDE features too, and Vim is easy enough to customize. (though not as much as Emacs, obviously)
.
I agree, and I think I've kind of trained myself to ignore it for the most part. Of course, this sets my ADD-addled brain off down a path of wanting to chase down every optimization for my ~/.spacemacs - thank you for that :P
VSCode is great and responsive locally on this macbook pro, and running locally on Windows 10 with a directory open in WSL is also very snappy. Unfortunately some of my work has to be conducted in an Amazon Workspace, which is so slow sometimes as to be unusable. So frustrating, and apropos of nothing, just wanted to rant!
I can only recall one time that Emacs has frozen up on me. When was the last time you used it? (I don’t doubt you, but with today’s machines the start up time is so small I don’t notice it hardly at all.)
The freezes most likely were due to various advanced language plugins.
But I think this is also a matter of perspective. Other developers don't understand why Jetbrains IDEs feel sluggish to me and think it might be my machine etc. (I have a very beefy one)
It's just that with (neo)vim, a fast terminal and no blocking plugins everything feels instant and extremely responsive.
What operating system is Emacs + Evil slow on, may I ask?
And which operations are slow? Emacs's term mode, shell mode, etc, are 100s of times slower than most terminal apps at scrolling thousands of lines at the user, which is a common part of the workflow of some C programmers. Is that where it is slow for you?
When I first started using Spacemacs, I wished that the Emacs instance had been trimmed down to the bare minimum. That way I could have more easily mapped my Vim knowledge onto Spacemacs without getting confused/distracted by the multitude of extra features and tools Emacs gives you.
I was wondering were that method were to be paired with a tutorial, if that would help ease people into Spacemacs/Emacs more. In other words, each step or lesson in the tutorial enables a new feature and explores it. So perhaps start with basic text editing, saving, opening, recently used files etc. Then add something like git or magit, and explore how that is used, then explore how the git and editing interact. Each new feature discussed would be like adding a new layer to the ~/.spacemacs file.
IMO, the most important Vim keystrokes for editing code are:
* %, which lets you hop back and forth between ()/{} pairs. Extremely useful when working with, say, Flutter.
* F/f/T/t (and ;/,), which let you jump to a specific character in the line, ahead or behind. This greatly sped me up, as I no longer needed to count out "okay, hop 16 characters to the left."
Also, another important thing is that Vim makes editing fast, not necessarily writing. There's not really much you can do to make writing faster in the first place, as you eventually have to type anything you write at least once in some form. But for editing, boy, is it great.
> There's not really much you can do to make writing faster in the first place, as you eventually have to type anything you write at least once in some form.
Well, that depends. It’s quite a bit like compression.
If you are doing something repetitive, which unfortunately is still necessary in some conditions for good reasons, Vim is good at this (and so are most other modern code editors; multiple cursors are surprisingly powerful.)
On the other hand you can always invent a shorthand. A popularized example would be emmet for writing XML, which is supported via plugin in most code editors.
I do a lot of WordPress hosting for large-ish non-software clients running one-off webservers that were setup by who knows years ago.
I certainly can and have automated stuff... but when I get a client who already has hosting setup, they just want me to manage it, not rebuild it.
As a sibling comment mentions, a lot of that is troubleshooting...
But making changes to stuff in /etc is an extremely common case where I just ssh in and use vim.
None of these clients have documentation on how the server was setup, much less any sort of way to set one up automatically. So there is a lot of "hey, can you up the max_file_upload for PHP" or "add a link to the hard-coded footer menu in our Drupal install".
And even when they want me to setup new stuff, they prefer me to just deploy a new instance and give them notes on whatever I do to it. Since these are 1-off things (like a server running some video conferencing or file management), there's not a lot of utility in build a script in BASH or ansible or whatever to build the server.
I'm a dev and the only one at the buisness where I work, so I'd be stoked to hear about some better way of doing work. But really, spending time in an SSH and configin stuff with vim seems like the fast, lightweight path for most of the work I do.
You try not to but sometimes when stuff is on fire, you have no choice.
Making a change to your cookbook/playbook/Dockerfile/<insert other automation verbage>, submitting a PR, waiting on a new build and deploying doesn't always cut it time wise.
Once in a while you need to just get in, make the change, and backfill the code changes in your build pipeline.
Making permanent edits? No. For debugging a b0rked system, yes. Unfortunately not every system is always optimally monitored if there are lots of teams so you sometimes need to get to the [Virtual]Machine and poke around.
vim is no longer an editor for devs but for system admins. I haven't used it to edit codes for maybe 10 years now that there are better alternatives having been through from SublimeText to Atom to IntelliJ now. (Yeah, missed VS code time.)
Using bash/zsh extensively, and Vim a few times a day, I have been wondering if people treat bash/zsh and Vim as two different worlds when it comes to keybindings, or is it common to use Vi/m keybindings in bash/zsh/other shells? Would love to hear some input on this! :-)
Personally, I have vi mode enabled for anything that uses readline. Some of my friends, though, have been reluctant to use it since the prompt doesn't indicate which mode it's currently in.
But... That changed with recent versions of readline, which introduced 'show-mode-in-prompt' [0]. It's somewhat limited - it only prints an indicator at the beginning of the last row of the prompt. You can, however, change what text is displayed. I use it to emit escape codes that change the shape of the cursor (similar to vim itself) [1].
They are two different worlds. GNU readline enforces the keys you might identify with Emacs and other GNU components that make their way into your GNU/Linux distro bundle.
Yes, and thanks!
In this case I was actually trying to understand how people in general try to combine the two tools. Keeping them separate, or using one keybinding for both! :-)
I have to routinely use VIM for SSH related in command lines and am pretty comfortable but in no way does it compare to VSCode with the small exception use case that happens to be quite common of hop-in and hop-out of quick changes. Vim shines there. It is just so light weight and quick for that.
> Display all lines that contain the keyword under the cursor. Filenames and line numbers are displayed for the found lines. The search starts at the beginning of the file.
:help [_CTRL-I
> Jump to the first line that contains the keyword under the cursor.
Both "] I" and "] CTRL-I" will start at the current cursor position instead.
I did not know about these, but now I am wondering how to reverse "] CTRL-I" and go to the previous result, as it seems quite useful.
The key is that it recursively searches (for instance in C++) header files for the word under the cursor and brings you to the first result. To go backward 'CTRL-O' jumps back in the jump list. I've not yet found a way to go to the next item in the '] CTRL-I' list. so I 'CTRL-O' then '2 [ CTRL-I', etc.
Btw, I just started reading SICP. How can I use Vim with Lisp code instead of Emacs? Because I did see people telling across the web that I should use Emacs for lisp code.
vim is definitely a great tool especially when you are editing/developing/viewing scripts within Linux. However, as soon as you start writing anything beyond one-file scripts, better move over to proper IDE, IMHO.
No need to give up on your favorite text editor: Spacemacs offers all the amazing IDE capabilities (Vimscript is simply a bad language compared to elisp) while still being one of the best VI-emulators around.
I disagree with your last sentence. I use vim exclusively. Granted, I don't use vanilla vim very often so I'm with you on the proper IDE functionality, but I disagree on what the proper IDE is :P.
Well, your comment came across as very snarky and negative, but I wanted to add some information however you intended that comment to be perceived.
I've been using vi/vim since about late 1996. I'm no expert by any stretch of the imagination, but it's like an old friend by now. It has been on every single system I've ssh'd into (as vi) and every system I've had configuration control over has installed vim. (recently via Puppet or Ansible, previously via Kickstart or setup script)
I've used vim for a bunch of different things. Most Linux distributions these days have a lot of sensible stuff already enabled to use immediately, and I've found that my customizations work really well across Linux, Mac, and Windows WSL v1 or v2.
Being able to rapidly transform a lot of text in a document through vim's composable commands is incredibly powerful. If you haven't tried it, run through a tutorial.
That could just be your bias and/or the fact that Mac users are the most numerous UNIX users (10x those that use e.g. Linux on any kind of desktop/laptop).
Tons of Linux users use Vim -- and Vim/vi of course has been popular for decades before Macbooks existed...
Enough, considering that group shots of CS departments, programming conferences, hackathons, etc, are always like 50% or more Mac or so (at least in the west)
You don't have to make that choice and can have "the best of both worlds": For the last few years I've not been using Vim itself, but Vim bindings in VSCode and Intellj. I enjoy the trade-off of this this approach because it
- is trivial to set up (in stark contrast to configuring a untouched Vim/Nvim install from the ground up)
- gives me simple access to powerful extensions
- allows me to use modern editor/IDE features (find usage, refactor) without forgoing "the essence of Vim", rapid code editing through the combination of motions & commands