In my book, it’s way better to install one Vim extension in whatever your favorite IDE is, than to install Vim with a hodge podge of 5 extensions and 300 lines of Vimscript. The keybindings are really the unique selling point of Vim, and you can get them anywhere.
I actually view this as another advantage of Vim; you don’t have to learn new keybindings every time you switch editors.
Qutebrowser is worth a mention too. Google has sufficiently neutered extensions that I fell out of the flow pretty often with Vimium (e.g., can't work on any of the built-in pages or some other Google properties), but having chrome exist at a much lower level and building the UI around vim bindings has made it a 10x better experience for me in Qutebrowser.
> The keybindings are really the unique selling point of Vim, and you can get them anywhere.
This is going to vary heavily from user to user. I'll admit it's been some years since I last tried anything new, but I never found Vim keybindings that were complete and configurable enough to comfortably replace Vim. It's always more like a UI uncanny valley in that the keybindings are relatively close, but imperfect enough that they interfere with my typical workflow.
Definitely agree. I've been trying to go full-Vim a few times over the years, and it's not been very successful. I'm a huge fan of Vim keybindings though, and wouldn't use an editor/IDE without support for it.
I would say that going 100% Vim is reasonable if you have a very stable development stack/environment. You spend a few weeks (or months, which is more realistic IMO) setting things the way you like and then use the setup for years.
If you work in several different languages, connect to several different databases, and also like to play with other tech stuff, VS code (and/or JetBrains products) with Vim bindings is usually more ergonomic.
Both VS code and JB have very nice Vim plugins, so you get like 80% of Vim power + a lot of polish and modern tooling from VS code/JB.
I've started full-vim and eventually settled for exactly that. It's been a success. Recently had to work from Windows after years on Mac, also using VSCode after years of Intellij and it wasn't a big deal because the Vim experience was mostly on par between Intellij and VSCode. I still prefer Intellij, but the remote coding (over SSH) experience on VSCode is just so much better.
there's also neovim extensions for vscode which uses neovim as the "server" so to speak that does vim things and then updates your vscode. in practice it works very well... especially the more recent updates to it. just have to have a neovim binary installed somewhere and point the extension to it.
Eh, I've never run into a vim emulator that didn't do something I used or the surrounding environment made it a hassle to integrate deeper. Vim is the entire runtime that also integrates with the Unix command line
Personally I like Vim because I do a lot of coding while in an SSH session and it's easy to port my setup very quickly. My work involves using a workstation with a GPU so I am not able to do that at home, and debugging requires me to run things from command line a lot to know what to change in the code. No doubt I could create a set up with a fancier IDE to do that, but at the scale I'm working in (academic code with just 1000s of lines of code) there is really no need.
You can do the same with vscode btw. I also work on remote gpu workstations and vscode remote with ssh works just fine, especially if you use tmux, you can preserve all the history and what you were doing.
I persisted with this approach for a decade. Enlightenment came when I let it go.
Even after 10+ years of daily use, I never managed to make navigating via hjkl work naturally with my brain — I need “up” to be physically above “down”. So I set up key bindings for the classic “inverted T” formation, dealt with the secondary effects, and I’m much more comfortable. https://github.com/rectang/dotfiles/blob/30e0a41714c34416f10...
Dare I say I use vim more like it was intended to be used with this new setup, as my right hand remains in place and is not constantly flying to the arrow keys and back.
Now I struggle a bit when I have to work on a stock vi, but that’s a very small part of what I do.
I use hjkl to scroll 90% of the time when using my browser. Having it on the middle of the keyboard where your hand rests make a lot more sense to me than weirdly angling your hand at the bottom right of my MacBook.
Ever since I learned how to use the Miryoku layout, I've been using vim with the hjkl navigation-keys shifted one position to the right. Those are also my arrow keys on a separate layer in the keyboard firmware. And I never looked back, this is how it really should be!
This also makes it easier to use the vim keybinding you find in many IDEs, as you are not relying on more arcane or customized bits of vim itself, but the general concept and common idioms.
I'm at this point. Learned vim in grad school where I was ssh'ing into systems all the time. I tried a variety of plugins but none of them have stuck for me. Now in industry everyone uses VS Code or something like it and I just can't get into it. Everything I need to do is on the command line (git, run tests, etc). Having been a Linux-enthusiast for quite some time helped me with needed command line tools as well (now I'm using a Mac at work, which is similar enough where it matters).
I stick with regular vi for a very long time because of this. I was a systems consultant way back when and I'd have to work on several variants of unix that had a mich-too-long lag time on getting vim ports. Iirc, sparc was the unix that took the longest in getting a gnu tools pipeline, so once they had vim and I could reasonably expect most of my customers could install it, I switched.
I now do a pretty standard config (mostly use the vim plugin in VSCode since I'm a software dev nowadays).
It blows my mind that there's so much devotion to the tool first, problems second, which must be mashed into a shape that fits my tool.
I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
> I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
According to the Zen master Dogen:
“Before one studies Zen, mountains are mountains and waters are waters; after a first glimpse into the truth of Zen, mountains are no longer mountains and waters are no longer waters; after enlightenment, mountains are once again mountains and waters once again waters.”
Like a lot of Zen things, this sounds like someone 'trying to sound deep'. But I'll try my best to interpret it charitably and maybe others can chime in with their interpretations.
It's safe to say most people see mountains as mountains etc. When you start practicing Zen, you glimpse into the inseparability of things: there is really no defined boundary between the 'atoms of the mountain' and the 'atoms of the water'. (Also the atoms themselves are mostly empty space with a probability distribution of where the 'stuff' 'is'). Things like 'mountains' are really illusory abstractions that humans build on top of the underlying reality of the swirling wave patterns of the universe. 'Existence precedes essence', as the existentialists say.
Still in this second phase, you notice things like when you have a conversation with another, the conversation is not really being generated by either brain, it is being generated by the system that includes both brains (and nerves, muscles, vocal cords, the air between them, eardrums, etc.)
However, after enlightenment, you realize that the underlying physics is no more 'real' than the abstractions, as the abstractions are what really has an effect on the universe. As Zizek might say, the distortion itself is the real. When I see a mountain, the way that my brain interprets it as a mountain, in effect makes it a mountain, because the symbol itself manifests itself in my thoughts and actions.
You use a tool enough and it shapes your way of thinking. It's like touch typing, you don't think about the individual keys you press. Instead you think about what you're trying to say/code and muscle memory takes over.
It's the same with vim. You start thinking "delete that word", or change everything until the '(' character. When you start thinking that way, changing the way you think becomes distracting.
> It blows my mind that there's so much devotion to the tool first, problems second, which must be mashed into a shape that fits my tool.
I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
I don't think there's necessarily a right or wrong answer, at some point I changed the way I think to match the vim model. Now I change things to match the vim model rather than change the way I think.
> You use a tool enough and it shapes your way of thinking.
Yes, that's true. I can't fathom writing Java in anything other than Intellij because it's shaped my thinking to "my tool should already know what this symbol is, where it is, and what arguments it might take". I guess it's shaped my expectations more than my thinking, but I hope you see what I mean.
> I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
Fair question. I guess my response is that one of the lessons I've learned the hard way in life is that my way of thinking can be wrong.
And while I enjoy a tool you can tweak to your desired tolerances, I prefer to use the tool that is most closely aligned to the task at hand.
You can get a nice even surface on a piece of timber using a chisel very carefully. Or, you can use a plane.
You can cut down a tree with a stone lashed to a branch, or you can use an axe with a metal head. Or, a chainsaw.
Changing between any of them requires a revision of how you think about the process, but it seems obvious that the cost of doing so might be worth it, even if the chainsaw requires changing how you think to incorporate concepts like kickback.
i can't not explain in words what it's like to use vim for 20+ years, esp to someone thinking an editor is "just" a tool. my vim config changes with me...
> It blows my mind that there's so much devotion to the tool first, problems second
What made you think that their devotion to the tool indicates that they care less about the problem? I wonder what you might think about me then in that I have vim integrated with mutt for composing emails, git, my password manager, code editor, text pager, etc land me in vim. I choose most my apps so that I can use vim for text editing. It gives me uniformity. It saves me time.
More importantly, I do not get a negative reaction from people that use different text editors for different text editing tasks looking for buttons to click, shortcuts to press in different places.
Especially nowadays, when tech is converging, getting locked down, and we are being told what and how to do things by a few companies, we must appreciate and encourage diversity of tools (except for emacs obviously:) that empower their users. Not be dismissive and judge them for using a tool that we don't use.
It's okay for people to master tools they find valuable, and use that mastery to do good things even if they're off-road tools (by today's standards) such as vim.
I find that some people really care about the work and that the tools are just a means to an end.
Other people love certain tools so much that "the work" is actually just an excuse to use their favorite tool in more elaborate and challenging ways. Their attitude is something like "and now for my next trick..."
The funny part, to me is that I've never been able to see one method as producing better results than another. I've seen work focused folks produce bad output and I've seen tool focused folks get caught up in their tools and never produce anything at all.
But I've also seen both types produce masterpieces.
Just different approaches and personalities I think.
I think a big part of it is just enjoying your time.
We're both driving cross country, following the speed limits. We'll both arrive at roughly the same time but maybe I'll enjoy my time more if I'm driving a stick shift.
This is in general of course. Me personally, I save tens of minutes a year by using vim.
I partly agree that it is a matter of personality, and that both can produce good results. But in my experience junior devs care more about the tools than seniors.
This sounds like a knee-jerk reaction that results from not having taken the time to make sure that the criticism lines up with the thing being criticised.
> It blows my mind that there's so much devotion to the tool first, problems second
The problem is clearly outlined here: "Manipulating raw ipynb files is difficult and unergonomic."
OP is not fiddling with his or her editor configuration because of any undue focus/deficiency regarding Neovim. The deficiency is in the Jupyter notebooks editors. In other words...
Problem: Jupyter sucks; my thoughts are always slowed down by having to squeeze them through a low-bandwidth link and the ergonomics hurdles that comprise basic text inputs--I want to go fast, but with Jupyter, I can't.
I mean, in mathematics a lot of problems are solved by realizing they can be turned into another tupe of problem that we already know how to solve.
If you know a text editor like the back of your hand, why would you learn another tool when you can take a different approach and be even more effective?
How many hours am I going to spend making my text editor work with this new problem? How long would it take to learn the new tool sufficiently to be reasonably effective?
I always remember a coworker who was determined to use Emacs on our Java codebase. He spent three months trying to get functionality equivalent to 2010 Eclipse (I was one of the IDEA hipsters in the company back then), and failed. Hard.
I always thought that in 3 months,n if he'd applied that effort to Eclipse, he'd probably be contributing patches to it.
If you swing a steel head framing hammer for 20 years, and then discover the lighter titanium one, I guarantee it will feel like nirvana. Tools matter.
I don't disagree that using the right tool for the job is important. In fact, that's kinda what I was going for - don't try to make the problem fit your preferred tool, rather, use the right tool.
Yesterday, I bought some nuts and wondered if I needed a nutcracker. I kinda dislike specialist tools. I prefer versatile ones. I found that I could just hold it in my hand and hit the nut with the blunt side of a chef's knife, turning the nut around and cracking all sides with precision. I could reliably extract the eatable inside part completely intact, not even split in halves. A specialist nutcracker tool is pointless to me now.
Because there’s a tool and there are (current and future) problems that can be solved with this tool. It’s an one time investment into a tool and it helps to solve multiple future problems more efficiently. Especially with vim or rather modal editing - this skill can be applied everywhere, including your favorite IDE. Though, it may be unrelated to the problem that OP was solving.
I've used Vim since I first managed to figure out a way to get a shell on the heavily controlled school Unix network. (Well, it was Vi initially).
It was always my editor of choice when SSHing into a box over dodgy dial-up for the very obvious reasons, a few keystrokes could be immensely powerful, and they're easy to transmit.
But I've never felt the urge to run Vim bindings in my IDE, or my browser. But for working on a file over SSH? Vim all the way.
It is good to have at least a basic understanding of a common terminal based editor. Otherwise it is very cumbersome to work with files on a remote server / ssh.
I find it fascinating that people think that optimizing a tool doesn't matter when they will be spending over 50% of their actual productive professional time in that tool. At least.
I use a similar setup in Emacs with code-cells.el [1]. VSCode had a tendency to choke rendering large interactive graphs in-line, so if I was needing to view in a separate process anyways a little elisp turns "write last IPython output to a tempfile, open, move to workspace N" into a keybind.
Edit: browser-based Jupyter would also fall down here as the penalty for a graph being too big is at least a kernel restart.
It's interesting to see this, I want to know about how others work.
But I've found with jupyter that it's most productive for me to just use jupyterlab in the browser, it has lots of features and for the visualizations that I do I need a good viewer. So vim doesn't work, and executing in ipython is like the console, not the notebook interface anyway.
I recommend using jupytext too, and then you can keep .py files as the canonical notebook files in your repo and code history.
From my perspective when I had to turn ML models from a "real scientist" to something I could use in production, emacs-ipython-notebooks[1] was immensely helpful for me, since it allowed to connect to the jupyter server and edit and copy things from emacs to other code places as if I'm looking at an org mode file.
I see the appeal of Jupyter notebooks for someone testing out things or experimenting, but it's a bit like a brain dump that isn't that trivial to navigate around when a second or third person is involved.
I use different tools, but what I do is insert image outputs inline with the calling code, in an Emacs text buffer. (emacs-gtk has native support for this). I don't have any explicit "notebook cell" logic. What I do is heuristically assume that an image object immediately following a code block is its corresponding output, and overwrite it on reevaluation. Very inexpensive hack that almost always does the right thing.
(Also, the image-invoking functions are just native functions in the source language, so I get a lot of orthogonality for free. For example, all the eval- and send-expr- style keybindings work automagically -- no need to extend the elisp language mode to special-case images).
I used to do the same, but I've been pleasantly surprised by VS Code's support for Jupyter notebooks. VS Code is my main editor, so it's really nice having all my familiar keybindings, plugins, VSCodeVim, etc. working out of the box.
I use IPython in a terminal and keep a Firefox tab open in a split screen to look at plots. When the IPython script is working, I write it out to a Python file. The only times I use Jupyter notebooks are:
1. If there's a really visually intensive workflow, like some sort of data exploration step where I need to be generating and inspecting multiple plots at the same time over and over.
2. If my goal is to make an instructional artifact and interleaving Python and explanatory HTML is helpful.
The VSCode Neovim plugin works with the Jupyter plugin for VS Code. So you can use your favorite editor inside Jupyter inside VSCode without having to change windows at all. It's a breeze
I have a similar setup with Emacs + Evil + Poly + Quarto Modes. Evil for vim keybindings, Poly to read cells as buffers and Quarto as a superior alternative to Jupytext [1].
Readit News
I actually view this as another advantage of Vim; you don’t have to learn new keybindings every time you switch editors.
Vimium radically improved my entire web browsing experience. I can't live without it anymore.
https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/
https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
https://homerow.app
This is going to vary heavily from user to user. I'll admit it's been some years since I last tried anything new, but I never found Vim keybindings that were complete and configurable enough to comfortably replace Vim. It's always more like a UI uncanny valley in that the keybindings are relatively close, but imperfect enough that they interfere with my typical workflow.
I would say that going 100% Vim is reasonable if you have a very stable development stack/environment. You spend a few weeks (or months, which is more realistic IMO) setting things the way you like and then use the setup for years.
If you work in several different languages, connect to several different databases, and also like to play with other tech stuff, VS code (and/or JetBrains products) with Vim bindings is usually more ergonomic. Both VS code and JB have very nice Vim plugins, so you get like 80% of Vim power + a lot of polish and modern tooling from VS code/JB.
How you know somebody doesn't have a clue what they are talking about.
That's like saying "chess is a bunch of nerds playing chess with more pieces."
I have yet to find an IDE that has integrated well with key bindings.
I beg to differ. The whole Vim is the selling point of Vim and that includes a fully functional Ex mode (command line).
Even after 10+ years of daily use, I never managed to make navigating via hjkl work naturally with my brain — I need “up” to be physically above “down”. So I set up key bindings for the classic “inverted T” formation, dealt with the secondary effects, and I’m much more comfortable. https://github.com/rectang/dotfiles/blob/30e0a41714c34416f10...
Dare I say I use vim more like it was intended to be used with this new setup, as my right hand remains in place and is not constantly flying to the arrow keys and back.
Now I struggle a bit when I have to work on a stock vi, but that’s a very small part of what I do.
``` " Make carat easier to type. inoremap <C-a> ^ ```
I now do a pretty standard config (mostly use the vim plugin in VSCode since I'm a software dev nowadays).
set tabstop=3 set shiftwidth=0 set autoindent
I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
> I don't think I'll ever describe myself reaching <X> nibbana, because, well, a hammer is a hammer, an IDE is an IDE, a tool is simply a tool, a means to an end.
According to the Zen master Dogen:
“Before one studies Zen, mountains are mountains and waters are waters; after a first glimpse into the truth of Zen, mountains are no longer mountains and waters are no longer waters; after enlightenment, mountains are once again mountains and waters once again waters.”
It's safe to say most people see mountains as mountains etc. When you start practicing Zen, you glimpse into the inseparability of things: there is really no defined boundary between the 'atoms of the mountain' and the 'atoms of the water'. (Also the atoms themselves are mostly empty space with a probability distribution of where the 'stuff' 'is'). Things like 'mountains' are really illusory abstractions that humans build on top of the underlying reality of the swirling wave patterns of the universe. 'Existence precedes essence', as the existentialists say.
Still in this second phase, you notice things like when you have a conversation with another, the conversation is not really being generated by either brain, it is being generated by the system that includes both brains (and nerves, muscles, vocal cords, the air between them, eardrums, etc.)
However, after enlightenment, you realize that the underlying physics is no more 'real' than the abstractions, as the abstractions are what really has an effect on the universe. As Zizek might say, the distortion itself is the real. When I see a mountain, the way that my brain interprets it as a mountain, in effect makes it a mountain, because the symbol itself manifests itself in my thoughts and actions.
"When I first began
To cut up an oxen
I would see before me
The whole ox
All in one mass.
After three years
I no longer saw this mass.
I saw the distinctions.
“But now, I see nothing
With the eye. My whole being
Apprehends.
My senses are idle. The spirit
Free to work without plan
Follows its own instinct
Guided by natural line,
By the secret opening, the hidden space,
My cleaver finds its own way.
I cut through no joint, chop no bone."
It's not the tool, but the wielder.
It's the same with vim. You start thinking "delete that word", or change everything until the '(' character. When you start thinking that way, changing the way you think becomes distracting.
> It blows my mind that there's so much devotion to the tool first, problems second, which must be mashed into a shape that fits my tool.
I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
I don't think there's necessarily a right or wrong answer, at some point I changed the way I think to match the vim model. Now I change things to match the vim model rather than change the way I think.
Yes, that's true. I can't fathom writing Java in anything other than Intellij because it's shaped my thinking to "my tool should already know what this symbol is, where it is, and what arguments it might take". I guess it's shaped my expectations more than my thinking, but I hope you see what I mean.
> I see it more of a question of, do you change the way you think to match the tool? Or change the tool to match the way you think?
Fair question. I guess my response is that one of the lessons I've learned the hard way in life is that my way of thinking can be wrong.
And while I enjoy a tool you can tweak to your desired tolerances, I prefer to use the tool that is most closely aligned to the task at hand.
You can get a nice even surface on a piece of timber using a chisel very carefully. Or, you can use a plane.
You can cut down a tree with a stone lashed to a branch, or you can use an axe with a metal head. Or, a chainsaw.
Changing between any of them requires a revision of how you think about the process, but it seems obvious that the cost of doing so might be worth it, even if the chainsaw requires changing how you think to incorporate concepts like kickback.
for some the journey is never the goal.
What made you think that their devotion to the tool indicates that they care less about the problem? I wonder what you might think about me then in that I have vim integrated with mutt for composing emails, git, my password manager, code editor, text pager, etc land me in vim. I choose most my apps so that I can use vim for text editing. It gives me uniformity. It saves me time.
More importantly, I do not get a negative reaction from people that use different text editors for different text editing tasks looking for buttons to click, shortcuts to press in different places.
Especially nowadays, when tech is converging, getting locked down, and we are being told what and how to do things by a few companies, we must appreciate and encourage diversity of tools (except for emacs obviously:) that empower their users. Not be dismissive and judge them for using a tool that we don't use.
It's okay for people to master tools they find valuable, and use that mastery to do good things even if they're off-road tools (by today's standards) such as vim.
Other people love certain tools so much that "the work" is actually just an excuse to use their favorite tool in more elaborate and challenging ways. Their attitude is something like "and now for my next trick..."
The funny part, to me is that I've never been able to see one method as producing better results than another. I've seen work focused folks produce bad output and I've seen tool focused folks get caught up in their tools and never produce anything at all.
But I've also seen both types produce masterpieces.
Just different approaches and personalities I think.
We're both driving cross country, following the speed limits. We'll both arrive at roughly the same time but maybe I'll enjoy my time more if I'm driving a stick shift.
This is in general of course. Me personally, I save tens of minutes a year by using vim.
> It blows my mind that there's so much devotion to the tool first, problems second
The problem is clearly outlined here: "Manipulating raw ipynb files is difficult and unergonomic."
OP is not fiddling with his or her editor configuration because of any undue focus/deficiency regarding Neovim. The deficiency is in the Jupyter notebooks editors. In other words...
Problem: Jupyter sucks; my thoughts are always slowed down by having to squeeze them through a low-bandwidth link and the ergonomics hurdles that comprise basic text inputs--I want to go fast, but with Jupyter, I can't.
Their solution: This.
What are the odds?
PS, describing my comment as knee-jerk is unhelpfully dismissive. I'm always keen to engage, and always happy to acknowledge when I'm wrong. :)
It's possible I missed something, but I didn't see the author being devoted to tools first, nor mashing problems to fit their tools.
If you know a text editor like the back of your hand, why would you learn another tool when you can take a different approach and be even more effective?
I always remember a coworker who was determined to use Emacs on our Java codebase. He spent three months trying to get functionality equivalent to 2010 Eclipse (I was one of the IDEA hipsters in the company back then), and failed. Hard.
I always thought that in 3 months,n if he'd applied that effort to Eclipse, he'd probably be contributing patches to it.
Because there’s a tool and there are (current and future) problems that can be solved with this tool. It’s an one time investment into a tool and it helps to solve multiple future problems more efficiently. Especially with vim or rather modal editing - this skill can be applied everywhere, including your favorite IDE. Though, it may be unrelated to the problem that OP was solving.
It was always my editor of choice when SSHing into a box over dodgy dial-up for the very obvious reasons, a few keystrokes could be immensely powerful, and they're easy to transmit.
But I've never felt the urge to run Vim bindings in my IDE, or my browser. But for working on a file over SSH? Vim all the way.
Different tools for different situations.
Edit: browser-based Jupyter would also fall down here as the penalty for a graph being too big is at least a kernel restart.
[1] https://github.com/astoff/code-cells.el
But I've found with jupyter that it's most productive for me to just use jupyterlab in the browser, it has lots of features and for the visualizations that I do I need a good viewer. So vim doesn't work, and executing in ipython is like the console, not the notebook interface anyway.
I recommend using jupytext too, and then you can keep .py files as the canonical notebook files in your repo and code history.
I see the appeal of Jupyter notebooks for someone testing out things or experimenting, but it's a bit like a brain dump that isn't that trivial to navigate around when a second or third person is involved.
[1] https://github.com/millejoh/emacs-ipython-notebook
(Also, the image-invoking functions are just native functions in the source language, so I get a lot of orthogonality for free. For example, all the eval- and send-expr- style keybindings work automagically -- no need to extend the elisp language mode to special-case images).
1. If there's a really visually intensive workflow, like some sort of data exploration step where I need to be generating and inspecting multiple plots at the same time over and over.
2. If my goal is to make an instructional artifact and interleaving Python and explanatory HTML is helpful.
It supports vim and emacs style key-bindings, and can display rich cell output like images and widgets.
[1] https://github.com/joouha/euporie
[1] https://quarto.org/