Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him.
Then one day we collaborated in my office instead. I use plain Unix tools, all independent. He watched as I did everything he did but with point-tools instead of a huge IDE. Rather than switching between files, I started a new terminal window and ran Vim. Other windows were for the build-run-crash loop, analyzers, note-taking, etc. Often I would do Vim tricks like doing a calculation by writing a formula on a line in Vim and piping the line to "bc" (`!!bc RETURN`). In fact, many of his IDE features I would access by calling out to external programs.
I had to hold back a laugh when he said:
"Oh my God! Linux IS your IDE!"
Well, duh. Isn't that's what Ken and Dennis created in the 1970s? Unix started out as the ultimate development environment! It just also happens to run everything else now.
- ctrl-E for "find and open in editor" (using fzf, substitute 'edit' with your editor of choice; the history gymnastics is to basically pretend that you typed it in manually for purposes of bash history)
- and of course, for german keyboard layout devs, rebinding capslock to alt-gr.
> Wonder if there could be a shell tool to just dump the first stackoverflow hit for a search.
There should be. I think `curl cheat.sh/programming+question` does that. There might also be a way to do that with surfraw. I just use DuckDuckGo, it almost always pops up an Stack Exchange answer in the sidebar when I search for something relevant to an SE.
I really love cht.sh, but find I never actually use it except for the occasional git syntax reminder. I think a flow that went `cht.sh -> fzf to narrow results and select a result -> vim -> OS clipboard` would have me using it all the time.
> and of course, for german keyboard layout devs, rebinding capslock to alt-gr.
I went the other way: use a US layout keyboard, and bind capslock to switch to German layout while capslock is being held down. I find that I need my fancy braces and brackets more than my umlauts. :)
I'm using US-intl (international) right now, supported everywhere I've seen. AltGr+q is ä, AltGr+s is ß, AltGr+y is ü, etc.
Might seem weird at first, but it has most of the special or combined symbols you might need, not just German ones. Other than that, it's your usual US layout suitable for vim/evil, shell, coding, etc.
>Though Google takes up a worryingly large fraction of it. Wonder if there could be a shell tool to just dump the first stackoverflow hit for a search.
I kind of thought it was a novel idea, but kind of pointless - if you know how to read a traceback you can Google it... but I guess it makes a lot of sense depending on your workflow.
`dirs` is a shell built-in for the directory stack. If you supply it with -v, it will number the output. So the trick is just to make these line up, which is also really just using a feature of `cd` that extracts an entry from the directory stack at position n. My aliases look like this:
alias dirs='dirs -v'
alias '1'='cd -'
alias '2'='cd -2'
alias '3'='cd -3'
etc.
Doesn't seem like it would make a big difference, but it's very fluid and adopts well to whatever "you happen to working on in the moment."
Okay, the actual fzf call is just the $(fzf). But when you use a keybinding with -x, your shell executes the command directly. So when you press return in fzf, indicated by the exit code being zero, we additionally do three things:
- echo a facsimile of the prompt followed by the edit command so that it looks like you just typed "edit filename"
- insert that facsimile into the history buffer so that you can redo the edit command with arrow-up
- actually start the editor
- and clear the commandline of anything you may have written beforehand, which would otherwise still be there and break the illusion.
The reasoning behind this dance is that if you just do an ordinary bind, you just get the edit_fuzzy call in your bash history, which is pretty useless. You want the actual generated edit call, not the edit_fuzzy call. So we use bind -x and "pretend that you typed in the edit call manually". We could just make ctrl-E insert the edit command into the readline buffer, but then we'd have to press return twice.
${PS1@P} is "PS1, expanded as if it were a prompt (P)".
fzf can be used as a cool selector in the terminal, it just outputs what you picked from the list, so if you run `ls | fzf`, it will pass the list of files/dirs into fzf, where you can fuzzy search, select and it outputs to STDOUT.
So if you want to edit a file from inside a directory easily, you can do:
In general though Emacs single handedly can do most of everything required in software development. One could practically spend all ones development time inside it, so I would say Emacs workflows are more impressive than Vi ones, especially since so much of great functionality is baked into it without even needing pluggins.
This I say after a couple of recent days in which the GUD gdb interface was a great help in solving a few of the problems I was working on. Does VI has something similar built in? Or for any of the common workflows like these which work out of the box, without needing plugins or extra configuration:
1. Remote file editing on other computers.
2. Rectangular/columnar text edits and manipulations.
3. Essentially infinite kill ring, i.e, a very easy to use copy-paste history: This I find is very useful, one becomes acustomed to building, blocks of text by assembling things from the kill ring. Also plays nice with point 4, easy macro record/replay.
4. Easy macro record/replay of even complicated edit sequences.
5.Inbuilt calculator, with both rpn and algebraic modes.
6. The Dir-ed mode provides a very convenient file manager.
> This I say after a couple of recent days in which the GUD gdb interface was a great help in solving a few of the problems I was working on. Does VI has something similar built in? Or for any of the common workflows like these which work out of the box, without needing plugins or extra configuration
Not quite, but the help page does mention a plugin called termdebug[1] that can be used with vim's new terminal feature.
> 1. Remote file editing on other computers.
The netrw plugin which comes with the default vim installation allows for this
> 2. Rectangular/columnar text edits and manipulations.
You can select text in column mode and delete, replace, or insert text before or after the column (which can be wider than a single column).
3. Essentially infinite kill ring : This I find is very useful, one becomes accoustomed to building blocks of text by assembling things from the kill rings. Also plays nice with point 4, easy macro record/replay
vim has registers that correspond to every ascii letter (I think emacs has this as well). From what I recall, when you delete or yank text, it goes through registers 1 through 9 which each subsequent operation shifting the previous operation to the higher numbered register. After register 9, the delete or yank is lost.
But, if you use the capital letter registers, you can append a subsequent deletion or yank to what's already in the register, which I believe would effectively act as an infinite kill ring. I'm not sure if emacs can do the same with its registers.
> Easy macro record/replay of even complicated edit sequences
Vim has this as well, and you can store one macro in each of the ascii letter and number registers as well.
> 5.Inbuild calculator, with both rpn and algebraic modes.
There may be a plugin for that, but you could certainly pipe a line of text through dc or bc and get the result in vim.
> 6. The Dired mode provides a very convenient file manager.
You can get this through the netrw plugin as well.
Even without resorting to external tools the expression register(:h @=) can act as a surprisingly good builtin calculator, and there is a moderately large builtin math library(:h functions).
Like all registers you can abuse it in many ways too, like as dirty inplace calculator when you're writing docs. For example, yank a example calculation, insert from register(:h i_CTRL-R_=), operate on your yank(:h @").
But are those functionality available natively without plugins? All these are in the default emacs distribution possibly since more than 20 years, and are in a very usable, stable state of functionality.
Sure but what’s the difference? That’s the beauty (and occasional curse) of Emacs. There’s no hard line between “native” code and plugins, outside of the Emacs Lisp interpreter.
Unix isn’t integrated enough. You can’t go very far with just throwing strings around (or bytes). You can’t safely refactor, say, Java code like you can do in Intellij.
Maybe you can piece something together manually that does the same thing, eventually. But if you have to do all of that work yourself then I wouldn’t call it integrated.
I think the point is that with *nix you aren’t just stuck with what some product manager at JetBrains thought was a cool feature.
And when you want to brew something up from scratch, or do the same task for the nth time, you don’t have learn how on earth this IDE implemented it, or learn a whole new API.
Take for instance an IDE’s find usages function, often a simple grey -r from a judiciously chosen directory gets you the same thing, but faster and more flexible (if your mind is wired that way, I suppose).
This winds up not being a big deal if you use grep a lot because you'll tend toward greppable names.
More importantly though, in a codebase big/complicated enough to need "find references" functionality beyond what you get from grep, do you not also have comments, reflection, and all manner of other garbage that you need to search for via some mechanism anyway?
For a few languages (more on the way) you also have semgrep as a way to add something a bit more powerful than "find references" into a normal shell workflow.
I have used `grep -r` a ton on our codebase and purpose-specific tools like “find usages” are always more to the point while `grep -r` can easily be misleading.
Also you can’t just tend toward greppable names (whatever that means) if you share a codebase with developers who are on Windows and wouldn’t be able to tell grep from sudo.
> I think the point is that with [Unix] you aren’t just stuck with what some product manager at JetBrains thought was a cool feature.
But you see that’s exactly what you are, because you can’t refactor Java code with what you call “Unix tools”. So your only option is to install actual IDEs on Unix.
And “find usages” finds... actual usages (e.g. method calls), not simple text matches which can end up being 80% noise. For `grep -r` you might try `Ctrl+Shift+f` instead.
I tried this approach for a while, and the thing I couldn't get my head around, is how do you undo mistakes? Like, you write a messed up sed command - are you supposed to revert your changes to the last git commit? Not make mistakes?
If I could work out a way to make undo as seamless and full featured as undo in, say, vim, then I'd be a total convert. Is there such a way?
In all fairness, is there ever really a water tight abstraction for undoing things at the file system level like you're talking about? If I'm ever trying to do some magic in a Unix-like environment, I usually always make sure that I'm using "dry run" mode if it's available or running the command against files that are in version control. On top of that, it's also essential to invest a reasonable amount of time into ensuring that the command won't run amok and start following symlinks or something like that. These are habits you have to develop if you want to operate at the command line level. IDEs often don't offer similar levels of power or control or the ability to cleanly undo large sets of changes like that.
I don't know of one - that's kind of why I'm asking. I don't think it's at all unfeasible (I think ZFS might do it, never tried it out) and I think it would be an amazing development. I think the unix model of one-purpose programs helps collaboration, maintenance, and produces higher quality programs. I just also think that because they're working in an environment that allows pretty simplistic interop (streams of bytes) and generally provides no history of changes, they tend to be fragile when used in concert, and brutally unforgiving when used alone.
If you could undo stuff easily, suddenly the 'brutal, unforgiving' part goes away, and it would enable a much more relaxing, explorative atmosphere, while also meaning people don't have to do stuff like 'alias rm=mv -t ~/.Trash' or whatever.
I studied piano full-time for a short while. My favorite thing about it was how working on my technique or a particularly tricky rhythmic pattern tickled my brain. I often found that I went through a few phases: “ahrg, this is impossible!”, “getting there but sloppy” and finally, often suddenly (after a good night’s sleep) “this is easy! I don’t know how I was ever not able to do this”.
Using vim and learning new features tickles my brain in kinda the same way. I don’t care much for the hacker credits. It’s a fun variety in my work day to practice some little feature that I read about, and it doesn’t look like I’ll run out of new stuff to check out anytime soon.
I never had the words to express that feeling. Tickling the brain is exactly the experience. I also love learning a new trick in Vim even after all these years.
I love the related "I know kung fu" feeling (from the Matrix) when you realize what was very difficult, or almost impossible is doable now.
Great feeling.
Yeah I went from notepad to visual studio to emacs to sublime text2 to vscode and finally gave up all that nonsense and got back on good IDE and got Clion. Simply the utility of the code refactoring tools completely blows any text editor out of the water. For example when I want to do a simple refactoring such as rename a function or a class I can do this trivially in seconds. I could never find anything like this for any of the editors I tried before. OK, I mean there's some clang based plugin for vscode for example but the the functions it has (such as code completion) basically almost never works and it has very little to offer in terms of refactoring.
That being said I adopted emacs style key bindings which I use continuously for the most common editing things. I find this is really the best bang for the buck and best of "both" worlds!
I'll stick to an IDE. Modern IDEs are sophiscated enough that a Vim/Emacs newbie user probably needs years of practice and tons of plugins to match and go over its capabilities. I think Vim makes a lot of sense when 1) the machine doesn't have a proper IDE, and 2) you really do a lot of programming every day and you are young, like in 20s, so you can amortize the cost for longer time.
I am making a game. I use Vim (infinitely faster and more product than other text editors) and write a single command in my terminal to compile. Vim makes a lot of sense when you want to work fast and don't want bloated development toolchains to slow you down. There's nothing in modern IDEs that would increase my productivity that I can't add to Vim in about 5-20 minutes.
I think I'll have an alpha/beta testing period with interested volunteers. Then hopefully sell it. Then after some years and waning interest, probably open source it.
Probably the best second person POV story I've ever read. Very funny and I got a kick out of it. As a relatively new part time vim user (about a year), I felt portions of this. I still use VSCode for a handful of tasks, but Vim has taken over more and more.
This past semester I had to SSH into our CS servers for my OS class, and the way my group would work was usually me sharing my screen and us peer programming. There were multiple occasions my group partners would stop me and ask how dude something like remove a full line, put it in a register, and pasted it at the bottom of the file so fast.
ddgp
I love the reactions to it, because people get excited and I encourage them to try him themselves.
I'm also very much an amateur when it comes to vim. I love seeing vim masters in action, it's so interesting. I think I'll forever remain the right eyed character who asks "how did you do that?", and it's that sense of wonder that makes me love vim.
I've tried the Vim plugin for VSCode a few times personally, but I don't trust it. It's incomplete, and it has its own secondary understanding of history that can get you into trouble when it interacts poorly with VSCode's own history. Anyway, that was my experience for my short time using it.
I'm curious if there are any longtime vim users using VSCode with the Vim plugin, and if so, what are their experiences, and why do they use VSCode with a Vim plugin instead of just using vim itself?
I used to, but switched to https://github.com/asvetliakov/vscode-neovim. It's much faster, doesn't lag the editor at all and has less of an impedance mismatch because it uses Neovim under the hood instead of trying to emulate functionality from scratch.
There are a few reasons why I use a vim plugin instead of vim proper for most day-day work:
1. I do plenty of data science-y stuff that requires support for good visuals. Vim's support here is pretty lackluster and Jupyter's Vim mode sucks. VS Code has a great interactive mode with full autocomplete and a dedicated window that records plots/output history.
2. Language servers and LSP plugins are so much easier to manage. I rarely if ever have to babysit updates and I don't have to install a bunch of system-wide dependencies to get certain ones to build.
3. Making the above (and all other fancy VS Code functionality) work on multiple remote machines is a breeze. The normal Vim workflow would require cloning dotfiles (not a big deal), running setup with something like GNU Stow (almost never installed) and then futzing around with LSP plugins as in 2).
4. Built-in rendering of rich docstrings/doc pages (think Markdown, Sphinx RST). I want to say certain extensions/languages support LaTeX as well, which would be a bear to read in Vim.
I know a lot of folks don't read comments over a week old, but just in case you do, just want to say: THANK YOU. I took the plunge tonight into neovim/vscode-neovim and it is the solution I've been wanting without knowing it was what I wanted.
I think I'm probably at a similar stage with regards to vim usage. I have mixed feelings about it, but it seems that VSCode has spread itself into my consciousness in the way that I had hoped vim would. With VSCode, I know how to quickly select a word, jump the selection to a multiselect, and rapidly selection by words or lines that I wish to edit simultaneously, all without touching the mouse. It's gotten to the point where selecting or jumping a word with alt-arrow is reflexive instead of `w`, where `ctrl-D` and `alt-down` are more reflexive than the more composable alternatives in vim. This ALL was supposed to be vim! Damn you VSCode!
I wouldn't be bothered by this except I compose Unix tools quite a bit, so it's like I'm maintaining two separate working environments. If I had just started with vim (or emacs) from the get-go, then these two worlds would eventually meet. I've even got my own handful of extensions to send things from VSCode to the integrated terminal and back as a sort of poor substitute for the things that emacs and vim have been doing for decades. I'm pretty sure that I'm an idiot.
Vim very much parallels a user's story with linux. Experiment just enough that you catch a glimpse of its true power and you become a snob. Your workflow is amazing and anybody who uses Windows/IDEs is a lesser mortal.
I will say that, while vim has a great, great many advantages, I'm often honest with those I'm trying to convert. Like the article said, there is a learning curve and you probably shouldn't try to gain the efficiency offered at peak work times, for e.g. with a deadline looming. Also, you accidentally hit a letter key and you can do something far less obviously wrong than inserting that letter into your text. But these are like getting a runny nose from a medicine that saves your life.
If your editor makes you significantly more productive, maybe you're just writing boilerplate code, or something someone already implemented in a library. Touch typing is similar - it's useful because it removes some unnecessary barriers and thus makes the job more enjoyable, but it won't magically make you a better a programmer.
The magic of vim is not really showcased when starting up a new, blank file in a new project. If that's all programmers did, we wouldn't need an editor at all: just cat > foo.c and start typing!
Where vim shines is with editing existing files. Sure, maybe your IDE has a great plugin (or great built-in support) for the specific language you're using in the project. But vim is excellent for editing any text file, no matter what language (or indeed no language at all), and its keys are always the same. If you become a vim master, you don't need language-specific support to be productive. Additionally, all of your knowledge of vim editing commands is transferrable to any kind of file you want to edit. Language-specific plugins, on the other hand, vary widely in capability, hotkey setup, and completeness.
So if all you do all day is work exclusively within a single language and you have your IDE perfectly set up for it, learning vim is going to feel like a waste of time. If, on the other hand, you find yourself extremely unproductive whenever you move to edit other kinds of files (and you need to do this a lot), then vim may be a worthwhile investment of your time.
This whole story gives me "hacker in movies" vibes. Programming isn't about artfully manipulating input devices while watching characters scroll fancifully across the screen.
It's about understanding a problem in depth, and considering possible implementations/problems/edge cases.
If you spend more time typing than thinking - I will unequivocally call you a bad developer (or a developer who's job is ripe for automation...).
---
Now - no knock on Vim. I much prefer it to nano, and if you enjoy using it, more power to ya. I do agree there's a certain sense of "playing a musical instrument" feeling to it.
But playing music and composing music are NOT the same. In the same way that entering text and programming are NOT the same.
Before becoming a coder, I was a professional musician and composer. I think you are completely correct on all counts, but I think the spirit of your post misses one important facet.
I compose because improvising on a single instrument is not enough for me. But it really is like improvising with edits, and being a good improviser will improve your compositions just as your compositions will improve your improvisations. And ultimately, you are doing these things because you love to play and hear music.
The appeal of vim is that it encapsulates programmatic thinking into the act of editing. With each edit, you are making a little program: "select these words with these conditions but not those other conditions, and then, for the first (expression x/y) of them, transform them thusly. Then, select the parent containers, and pipe each one to this file-descriptor to be processed externally."
But you can do this with a few keystrokes, you just have to think ahead a little. That is, it makes the act of programming and entering/editing text one and the same activity, allowing you to do little programmatic improvisations.
I switched from music to code when I realized I got more enjoyment out of code than music. That is, I echo your statements "if you enjoy using it, more power to ya" and "playing music and composing are NOT the same," but also: sometimes playing music and composing are the same, and sometimes the only reason you are composing (or playing music) at all is because it feels so wonderful to do both at the same time.
Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.
It's not about typing speed, it's about reducing mental load. When vim (or any editor for that matter) becomes second nature, you stop thinking about how you're editing the text, it just happens, like moving a part of you body. And then you can better concentrate on the problem at hand, which matters even more for solving novel problems/algos/architecture.
Same with touch typing: you don't need the speed, you need to eliminate the distraction of looking for a key.
Even when you're debugging/reading code, you're still making small changes: adding a print here, removing an argument there. I read somewhere that the main insight behind creating vim was that you spend more time moving your cursor and parts of code around than you spend writing new code. So that's what it optimises for.
Well I guess then it is different for each person what induces mental load. I for one sometimes just use my mouse to click and copy things or insert a character here and there or to go to some other line. Why? Because I can think about the next problem while I do that because I don’t have to think about any keystrokes.
Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people.
To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.
I feel like you and I work on very different types of code. If I tried to do what you suggest, I would be adding comments and assertions for days. Also I follow the school of thought that code should be self explanatory and comments should make statements about the trade offs you made from a business or systems design standpoint, not explain what the code is doing.
I feel like the approach you are taking is impossible with the I inherent complexity of the systems I work with and for me the only chance is to follow a trail of a data point through the system like in Hansel and Gretel and see what effects it has on certain objects in a debugger.
I don’t use the debugger to understand code, I use it to find out why my tests are failing, where in the system the faulty data point comes from and if the values in each step behave in a way that is acceptable.
The second big use case for me is exploring in the debugger REPL what would happen if I change value x to y or test lines of code before I put them in the unit test, because I can only run the test a limited number of times per day since it takes like 5 minutes to boot up. I have to be very careful not to waste computer cycles.
Styles differ, but for me using actual runtime behaviour to guide my reading of a code base is often a LOT faster, and your approach ends up boiling the ocean.
The way for this activity to benefit others is to use your improved understanding to refactor/simplify the code you are working with to make it clearer for someone else to understand at first reading.
Personally for me many systems only clicked after seeimg the, from the inside.
Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well.
I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).
I work with big data and have to solve a lot of problems in integration or by debugging again at the a live Systeme, which you simply cannot reproduce in local unit tests.
And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.
> I don't understand - how is using a debugger a waste of time?
The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does.
The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.
If code had instrumentation for every variable someone ever looked at with a debugger it would be unreadable because it'd be buried under instrumentation code, configuration to only enable instrumentation when needed, ... That's not to say instrumentation/logging/... aren't useful tools that can be more appropriate, but "never use a debugger" seems like a misguided dogma that seems surprisingly common. Part of the strength of a debugger is being able to look at all the things to find the ones worth a closer look, without having to add instrumentation or logging to every single one.
> by adding [...] comments, [...] etc
If you need a debugger, those are not there or not good enough, and you can only meaningfully add them after you understand what's happening.
(EDIT: there is also a wide variety in what people count as a "debugger" further muddying the debate)
I feel like your understanding of a debugger is very limited.
To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project.
A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing.
Not even touching the places where a debugger solves a problem you simply can't touch with instrumentation after the fact (crash dumps immediately come to mind...).
And neither of them are (in any sense) a replacement for writing a test after you solve the problem, or adding comments so the next developer has context on the why of that piece of code.
First of all, I agree 100% that a debugger is an indispensable tool. I just say that it is often not necessary or useful when you are writing new code or reading old code that you are supposed to edit. Your example about interpreting a crash dump is definitive.
I've had a fair share of using debuggers in my life, and I ended with my anti-debugging stance as a matter of fatigue, and a sense of time lost. I know what debuggers are capable of, especially regarding data visualization. But for your example of the variable watch, what are you going to watch, precisely? That the value of a variable is always positive? That it increases one by one? All these things are better served by assertions. What kind of information can be inferred by just looking at the evolution of values of a variable that is not easily formalized as an assert or a simple in-code test?
It's weird to write the test after solving the problem. You should write the test before solving the problem to get the most benefit. You can then edit + compile + run test until the test pass and normally this is shorter than the "edit+compile+start app+replicate bug manually in application+debug" loop.
Depends on the bug - most times I'm breaking out the debugger it's because I have a timing/race condition somewhere, or an unexpected interaction with some other service/component.
Basically - the debugger is not a tool I use if the issue is clear and reproducible.
Those are also issues where it can be hard to write a correct test up front. Typically - tests are passing already, but we're seeing intermittant problems somewhere. Once we understand the interaction and the root of the problem, it's much easier to put a test in place.
I agree, but I think it is also like learning Lisp. I don't program in Lisp, but I think differently about some things because of it. Like code as a list that can be manipulated. Code as data, which is similar to Vim. Vim encourages thinking about things in terms of a language that represents structural units. I think more about how to code is structured rather than thinking about it as just freeform text with semantic meaning.
Whether that structural mindset helps with programming.... Dunno.
Lots of times you could write something more succinctly with less boilerplate using, say, C preprocessor macros, but then end up losing out on debuggability, and sometimes searchability. Complex block based editing etc. is useful in those situations. It's a limitation of the tools.
I’m a Vim user and proponent so don’t get me wrong here, but is “creep” in the title intended to be a description of what Vim does, or of the Vim user/protagonist? :)
Does anyone have any good recommendations for screencasts of advanced Vim usage? I'm pretty comfortable with the basics (I'd say my level is "try to use macros sometimes and find them too clunky"), but in these days of remote work I don't get to look over my co-workers shoulders too often, so I don't feel like I have a good idea for what I'm missing. Less "here is the way to do this thing" and more "watch this wizard at work and get inspired, maybe with a bit of commentary."
Drew Neil's awesome vimcasts¹ are available, while no longer getting updates they'll still be pretty useful. Also a /big/ fan of his Modern Vim book², even after literal years of vim use I still found a bunch of new-to-me information inside it.
Man. This is honestly every Vim user story. How I despised Vim/Nvim in the early days of me using Vim. Now, its all past and Vim is my workflow. Browser, TUIs, etc etc you name it.
Once nvim-dap starts working well. I am not going to even install VS Code. For now, debugging is a real pain in the ass.
This resonated massively with me. I'm very glad that at some point in my university days I started to play around with Vim and today I can benefit from the muscle memory in almost every application I use, even if I hardly ever use Vim directly anymore.
I've programmed for a long time, since before the days of personal computers and graphical terminals (unless you count oscilloscope like vector graphics output devices). So, I'm quite comfortable at the command line and use it all the time. I think it's interesting that there are nevertheless a few tools that I find indispensable which don't run in a terminal: obviously, the "big" graphical apps (like those from Adobe) and web browsers, but even my apple track pad for scrolling works so well that there is nothing quite like it.
Can you recommend some resources about using Vim effectively without turning it into an IDE? I'm a self-learned Vim user and I'm sure I could learn a lot by observing experienced vim users.
Kakoune has ambitions to be the true "unix way" editor, but it makes some very questionable design decisions like plugins made in shell scripts. For the sake of compatibility. Neovim's decision to fully support Lua appeals to me much more, I mean it is a compromise but a good one. It's a good and fairly popular language.
I'm a self-learned vim user too. I been using vim the wrong way till i watch this video,
https://www.youtube.com/watch?v=l8iXMgk2nnY
VIM tutorial: linux terminal tools for bug bounty pentest and redteams with @tomnomnom
Now I keep my vimrc simple and use neovim for more complex stuff.
I had this experience a few weeks ago. I was showing a colleague something, using vim as normal, and he started shouting "Whoa whoa! What are you doing? You don't use a mouse?"
If you're annoyed by typoing stuff, like I'm annoyed by typing :Wq or :WQ, you can just alias it of course. Since you (and, presumably, nobody) ever use(s) vim encryption it doesn't matter to override it.
vimrc:
command Wq wq
command WQ wq
command W w
command Q q
I often use a debugger (PDB++ or PuDB in Python) in my terminal, which I have open alongside Vim. But Vim historically has lacked strong IDE-like features, especially compared with Emacs.
This is starting to change with Neovim v0.5, currently only available on Git master building from source. But it's worth building from source, because it's a completely different text editor. Especially when you use a nice GUI frontend for it like Neovim-QT.
With the plugins nvim-lspconfig, nvim-treesitter, and nvim-dap, and plugin manager packer.nvim, you significantly close the gap between Neovim and Pycharm. I used to use Neovim for light duty programming and Pycharm for anything "serious", but with v0.5 and the plugins above (among others) I just use Neovim for everything.
The downside is that, because it's all very new and in alpha/beta state, the documentation isn't too thorough and things occasionally might break. But personally I haven't had any trouble with breakage, and the default plugin configurations do mostly what I want with only minimal fiddling. And if you're on Mac you don't even have to download a tarball and read the build instructions, just `brew install --head neovim`.
Neovim v0.5 is leaving Vim in the dust IMO. It's more like a Lua-powered LSP/DAP/Treesitter-based IDE engine than a text editor. Except it's also just a text editor and it still opens in less than 1 second.
IMO if you want an IDE use an IDE. There are a wealth of plugins that attempt more or less successfully to bring IDE-like features to VIM, but I'm not sure I see the point personally, it'll never be as seamless as an IDE built and maintained from the ground up to do these things. I hear that many IDEs have semi-competent Vim-style editing support, so maybe that would be more to your taste.
If you want to try the Vim experience I suggest doing it the Vim way, use a minimal config when starting, only add plugins after careful consideration, prefer simple generic tools like grep/rg, FZF, dumb completion and ctags over complicated tight integration with language servers and debuggers.
But maybe you prefer more integrated environments and that's perfectly fine, but in this case I wouldn't recommend a switch to Vim unless you have a very good reason to want it.
Without plugins Visual Studio Code in principle is just an editor. Yet even without any plugins or language-specific support it still a better tool for development out-of-the-box than Vim or Emacs. It can quick open and search across a development tree with thousands of files with no configuration.
So as an editor for config files and small projects Vim without plugins is OK. But that basic Vim experience just does not scale. One does need plugins with Vim for anything big.
I mentioned FZF (with Rg) with IMO is a great plugin to use. With it you can explore huge projects very quickly without requiring any language specific setup. Vim also supports tags files by default which can be quite nice when browsing large projects, just run universal ctags and you can cross reference symbols for most languages.
Actually the only project-oriented Vim plugins I use are FZF, editorconfig and fugitive (git interface). The rest are just editor tweaks such as vim-unimpaired and vim-surround. And I regularly deal with very large codebases such as the Linux kernel, so at least for my use case it scales reasonably well.
Checkout chromium and try that on its tree. Or rgrep. Then try searching it with vscode and compare the timing especially with second and following searches. And vscode is smart enough to search files that where opened recently first bringing useful results instantly.
Of course if you need to cross reference the entirety of a gigaproject like Chromium you're going to need some sort of a cache and smart search. If I was a Chromium dev I'd probably set something up to help with that.
99.999% of source trees are a tiny fraction of that size however.
As I mentioned in another comment I routinely hack in the Linux kernel which contains about 15million SLOCs (per sloccount) and ripgrep takes less than 5s on a cold run and is near instant after that. ctags lookup almost instant regardless of cache. And that's on a 5 year old middle of the line SSD and CPU.
Inability to easily deal with chromium-sized repositories out of the box might be a deal breaker for you but it's a total non-issue for me.
> One does need plugins with Vim for anything big.
When a fresh shell tab is just a command-T/ctrl-T away, you don't need Vim to do any of these things in the first place. The point of Vim is that it's a text editor that lives in an environment where you can already accomplish everything other than text editing.
VSCode is a text editor that uses plugins to bring other programs into VSCode. Vim is a text editor plugin for an environment in which all those programs already run natively.
The problem with basic Vim is that it does not support out-of-the-box tools that can run longer than an invocation of a single command, like language servers, project indexers, tree synchronizers etc. ctags etc. just does not scale. And on Windows and to lesser extent on Mac one needs that even for medium-sized projects.
For Python vim is allright. The probability of making syntax errors is a lot lower than with languages like Java and you can see them without going through a build. But language servers are the only way to make vim an acceptable choice for a lot of other languages. Otherwise your productivity is just much lower than with an ide. Personally i use vim for terminal work, searching, merging, editing sql and other files, sometimes building and Eclipse for coding on my current project.
If you want to have it the other way around (having Vim inside your IDE instead of turning your Vim to an IDE) I’d suggest you to try IdeaVim [0] with PyCharm. Works very well, you can even use your own .vimrc file.
Had a few days off and dived into my vim setup /plug-ins for python, but ended up with pycharm again. I could emulate most of pycharm (pros) features, but what made me end up going back to pycharm was the refactoring capabilities. Rope just didn't come close, while pycharm makes it trivial and rarely misses anything. Well that and having to manage all of these plug-ins on different OS/ python versions can become a time sink too. E.g. started out with vundle, but it did not support some of the features I needed to get an older commit of a plugin that was barely maintained anymore, so ended up rewriting the.vimrc with a different plugin manager... Etc etc
I use vim (neovim) for everything, but particularly for Python dev. The trio of Linux, tmux, and vim is a powerful combination for any language/framework IMO.
My workflow recently has been CoC.nvim (coc-python plug-in) which lets me integrate flake8/pylint for linting, jedi for completion, and black for auto formatting.
For me those three, linting, completion, format on save are the only IDE like behaviors I need. With Python3.6 or better, I can insert a breakpoint manually whenever I want.
I've been using vim for a bit over a decade now. But throughout that time I bounce between actual vim and vim emulation. Lately I've been concluding emulation is better most of the time.
The problem with real vim is maintaining your setup can be super painful. 95% of the time it's fine, but that 5% can really bite you. For example, this bug, https://github.com/tpope/vim-vinegar/issues/10, struck me out of nowhere. It was super annoying, and took some debugging and exploration to find a work around for. As you can see from the comments, it seemed to impact like 5 people, so you often don't have the advantage of a large audience pushing for fixes. In the end the bug was in vim itself, not the plugin btw.
With all that said, in my humble opinion I would say start learning real vim with say vimtutor (it is possibly already installed on your machine) and use vim to say edit config files or do git commits. When you are getting comfortable with the vim way of editing, switch to an emulator in your IDE. IdeaVim for the IntelliJ family is really good, that's what I use today.
I've been using an almost stock installation of spacevim both in gvim and terminal for the last couple years. It's sort of like a distro of vim plugins dialed in to play nicely together.
PyCharm + IdeaVim, the best Vimemulation i tried so far (VS, VSCode, Spacemacs). It supports Macros, you can use parts of your .vimrc and they ported several plugins, vim-surround and others.
This is good. It reminded me that "vim" is actually a word: "with vim and vigor." It's an appropriate word. Sort of like a retroactive nominal determinism, because it's "vi-improved", so the Mooleanaar probably didn't name it because vim means energy, but, basically that's what it means for a lot of programmers (including me). All these years, I never recalled the connection between the word and the name of the tool, until reading this story! Great!
> You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse.
You mean: spend untold hours scripting and recording interactions that give you about 10% of capabilities of a modern IDE.
I've personally seen long-time vim users switch to Idea after looking over my shoulder.
> You mean: spend untold hours scripting and recording interactions that give you about 10% of capabilities of a modern IDE.
For information, not all vim users are trying to reimplement the capabilities of a modern IDE in vim.
Some of us are just fine with vanilla vim/vi (and derivatives) because we are comfortable enough with the *nix environment [1] and don't need IDEs' fancy GUIs and integrations with stuff such as code completers, repls, debuggers, tag browsers, linters, etc.
In my opinion if one needs the full capabilities of a modern IDE right in their editor one should go with a modern IDE.
Trying to turn vim into a modern IDE with a zillion of plugins and glue scripts is a leisure activity and a time sink. Or just for the people who want to look cool [2].
I think this is the mindset you are criticizing.
[1]: Read: Already "spent untold hours" in the past, for better or worse
[2]: This is not bad per se. How are we going to impress nerdy girls otherwise? Your development environment doesn't always have to be about "work". Some people are also understandably after a certain kind of "hacker aesthetics". I mean looking at Idea's interface you can't feel like Neo entering the Matrix. Who cares about productivity??
> In my opinion if one needs the full capabilities of a modern IDE right in their editor one should go with a modern IDE.
> Trying to turn vim into a modern IDE with a zillion of plugins and glue scripts is a leisure activity and a time sink.
Haha. That's true :) It's possible there's this conscious/unconscious bias against IDEs and "all the cool kids use vim/emacs". So people use those editors, but consciously/unconsciously crave the quality-of-life improvements that many IDEs (or just many other editors) provide. Even the simplest ones like file lists. Or symbol look ups. And then, yeah, it's down the rabbit hole of chasing the plugins, and configurations, and scripts.
I experienced all this myself with emacs (I never grokked vim beyond some basic commands).
For example: in VSCode you can select/hover over any expression and it’ll tell you the computed TypeScript type. None of the current language server tools for Vim (eg ALE) give you that information [0]. Why would I live without this useful feature just to use Vim? I love Vim, but I love knowing the type the TS compiler thinks an expression is even more, especially when good enough Vim emulation is available.
All LSP clients for vim will give you that; it is whatever command calls `hover` on the language server (e.g. ALEHover for ALE or LanguageClient_textDocument_hover for LanguageClient-neovim). Obviously you should bind these to some convenient command like <leader>t.
Like many things in vim it depends on whether you wish to write it ;)
You can define your own popup(:h bexpr) however you feel, including per-filetype or buffer. Instead of simply operating on the variables it defines to you can also work upon the selection by querying the register(:h quotestar) instead.
As an example, I like displaying wordnet¹ popups when writing prose. Occasionally, I'll also dump diction² output in to a popup too.
However, I do think that using messages(:h :messages) might make more sense for selection info in general. That way you can select a text, call a map to display information, and still easily recall that data when you're in another place via :messages at a later time. Depends entirely on your use case, and once again how interested in writing the functionality you are.
Clearly there are many areas where vim is not the best tool for the job. Would you mind sharing a couple of examples of the context and the IDE features that made long-time vim users make the switch?
This was about three years ago, and the codebase was a huge Symfony project, in PHP.
- IDEA understands bindings to Symfony's sprawling YAML configuration files. So jumping between PHP code using a config value and the YAML file defining the value is one shortcut/click away. And more, and more: https://www.jetbrains.com/help/phpstorm/symfony-support.html
I think searching was the primary thing that drove people to try IDEA. And I've seen it again and again with emacs and vi users: they spend significantly more time searching for code than I do. Because most of the time the best you have grep/ag/ripgrep which just search through files as and leaves figuring out context to the user.
- Usages. Shortcut/Cmd+Click on anything, see where that anything is used/invoked. Without searching. https://www.jetbrains.com/help/idea/find-highlight-usages.ht... That was another big thing that fascinated people. Very useful in large legacy projects.
This is off the top of my head for that particular job.
But in general, there are significantly more things like identifying errors and suggesting fixes, large-scale refactorings, understading the plethora of test frameworks and letting you run the tests however you like, debugger integrations, stepping through automatically disassembled code for Java and .net during debugging etc. etc.
Thank you for taking the time. Regardless of what tools we choose ourselves I think it's very valuable to know what features are available and appreciated elsewhere. IDEA certainly has some impressive features.
No problem. IDEs quite deservedly have the reputation of bloated monstrosities, so people might be put off by them. Hoewver, these monstrosities often have a plethora of tools that you might not even know can exist unless you use one of those monstrosities :)
For me Vim’s value is as a great programmer’s editor, not so much as an IDE. There are a few things I have made or installed that I just could not live without:
* CamelCaseMotion, allowing select/delete/change of just one or a number of segments of a camel case or snake case name
* surround.vim, allowing single commands to (for example) change the () surrounding a text to [] or “ to ‘
* a simple one-liner to change a literal Python string to a f-string and back without losing the current edit position
And in general the power of the motion + action vocabulary that lets you compose edits on the fly once you have the motions and actions under your fingers. You don’t even have to think to type ysiw” to put “ around the current word, for example, or vt)~ to change the case of everything up to the next ).
> You don’t even have to think to type ysiw” to put “ around the current word
I just select the word (Option/Alt + ArrowUp) and press “. Same for parentheses, brackets, curly brackets and single quotes. ;)
> or vt)~ to change the case of everything up to the next )
Since selection in IDEA is context-aware, pressing Option/Alt + ArrowUp will select the word, then the group (e.g., an expression in parentheses, or a key-value pair in HTML/JSX), then the outlying group (e.g., the scope block, or the tag) and so on up until the full file is selected. For any context/group.
It doesn't have a built-in camelCase transform, but there is a plugin :)
So, in general, an IDE usually provides a much more generic set of commands that are applicable in a wide variety of situations, and that are usually context-aware. Not some very specific situations like "if I'm in this particular place, and I do this particular thing, then do that particular thing".
Depends on the language you're working in. I work in Ruby and as good as RubyMine's refactoring is, it can never be 100% because Ruby's a dynamic language. There are a lot of RubyMine "power users" at my office and, other than less than perfect refactoring, I haven't seen anything it can do that vim can't do. In fact, when it comes to navigating files, rails.vim seems superior. The only thing I'm jealous of is the built-in terminal that has tabs within the main screen.
Reminds me of this story...
Two years ago I was collaborating with a coworker. Most of our time was in his office. I would look over his shoulder as he typed. He had recently adopted a new IDE and spent considerable time configuring it and learning its features. He was very proud of how productive it made him.
Then one day we collaborated in my office instead. I use plain Unix tools, all independent. He watched as I did everything he did but with point-tools instead of a huge IDE. Rather than switching between files, I started a new terminal window and ran Vim. Other windows were for the build-run-crash loop, analyzers, note-taking, etc. Often I would do Vim tricks like doing a calculation by writing a formula on a line in Vim and piping the line to "bc" (`!!bc RETURN`). In fact, many of his IDE features I would access by calling out to external programs.
I had to hold back a laugh when he said:
"Oh my God! Linux IS your IDE!"
Well, duh. Isn't that's what Ken and Dennis created in the 1970s? Unix started out as the ultimate development environment! It just also happens to run everything else now.