Vim Creep (2011)
rudism.com
rudism.com
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.
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.
bashrc highlights: https://gist.github.com/FeepingCreature/649588a2f6fa27c717bd...
- ctrl-G for "directory up"
- 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.
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.
"How can I have a shortcut that I type, then enter a search query and have the first result open automatically?"
... for cd ../..
....
.....
They compose naturally too, ..../targetDir
I use these so frequently and naturally that I forget that they aren’t built-in to my shell.
Also, a shortcut to jump between the last 5 or working directories. Print them with `dirs` and cd to a directory by invoking its number.
alias dirs='dirs -v'
alias '1'='cd -'
alias '2'='cd -2'
alias '3'='cd -3'
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."
I saw this yesterday and your comment reminded me of it: https://github.com/danrobinson/tracestack
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.
So if you want to edit a file from inside a directory easily, you can do:
vim $(find | fzf)
- 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)".
I use https://github.com/samtay/so, which lets you search any stack exchange site (SO by default). It's fully terminal-based.
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. :)
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.
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 @").
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.
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.
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).
Edited to complete fragment...
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.
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.
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.
"refactoring java code" is really not an exceptional task that vim (or emacs) cannot handle.
In situations where grep -r is too stupid, ctags exists.
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?
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.
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.
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!
But for doing proper application work, refactoring, debugging — I’m with you. I might be good at vim but gdb is a whole different beast.
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.
Also, have you tried the Vim plugin for VSCode?
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?
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 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.
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.
Whether that structural mindset helps with programming.... Dunno.
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 don't often use a debugger, but they have proven to be useful in a lot of cases.
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).
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.
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.
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.
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?
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.
> 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 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.
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.
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.
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.
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.
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.
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.
Now I keep my vimrc simple and use neovim for more complex stuff.
"Vim!"
https://mobile.twitter.com/vasudevram/status/133781328616362...
:wq ?
> Like “:wq”, but write only when changes have been made.
https://til.hashrocket.com/posts/2fdb6afb66-difference-betwe...
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 qMaybe I'm over complicating it, anyone have a python based suggestion?
As a note, I do not have local admin but Vim is installed already.
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
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.
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.
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.
git grep
?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.
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.
ⓘ This claim is disputed.
> It can quick open and search across a development tree with thousands of files with no configuration.
M-x find-grep would like a word.
Before you say anything, Visual Studio Code depends on (and bundles) ripgrep to do its fast searches. (Emacs defaults to using your system's grep.)
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.
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.
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.
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.
Goto definitions, intelligent autocomplete, inline diagnostics, smart renamers, type hints and more are all available.
All with very little configuration and it works the same no matter the language (as long as it as SLP support).
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.
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.
- 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
- Refactoring: even a small thing like renaming a variable, a method, a config value. Changes propagated through all affected files (with preview of changes). It's impressive even for dynamic languages like PHP: https://www.jetbrains.com/help/phpstorm/refactoring-source-c... For languages like Java? Oooh, boy, see submenues on the left https://www.jetbrains.com/help/idea/refactoring-source-code....
- Symbol search. You know a function name, you can't remember the file? Symbol search for the function name. It's fuzzy, too. https://www.jetbrains.com/help/idea/searching-everywhere.htm...
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.
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??
> 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).
There's nothing "mouse-driven" in developing with IDEA. Well, except window/panel management. It is objectively bad.
* 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 ).
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".