There's much to say about "wasting" your off time by learning your editor.
I still remember this one time, 15 years ago, where I spend literally the whole night configuring my .vimrc, reading the :help pages for all of the configuring options, doing the tutorials, and just moving around and getting comfortable with it.
At 8PM that night I didn't know Vim, but by 6AM the next morning I was very productive in it. I'd say about 80% of my productiveness with Vim was achieved that night, and I could never change to a non-Vi editor since.
Feels like they all try to make vscode out of vim. Is there a truly vim-spirited LSP plugin? The one that doesn’t flicker on its own when you type, and only shows issues in quickfix after :make equivalent, even if it works asynchronously (works with Vim would also be great). I don’t mind configuring it for a week, but what’s on gif-shots usually repels me.
Basically all you need is nvim-lspconfig, which just attaches the language servers to your buffers (so you wouldn't even need that, but it saves a lot of boilerplate). From there you can use all you already know (this is from my Lua-based config, but you can do the same in Viml):
vim.keymap.set("n", "K", vim.lsp.buf.hover, { buffer = buf })
vim.keymap.set("n", "<leader>qf", vim.diagnostic.setqflist, { buffer = buf, desc = "Quickfix diagnostics" }) -- open Quickfix with LSP issues, Loclist possible too
vim.api.nvim_buf_set_option(buf, "omnifunc", "v:lua.vim.lsp.omnifunc") -- use LSP completion for omnifunc
vim.api.nvim_buf_set_option(buf, "tagfunc", "v:lua.vim.lsp.tagfunc") -- Ctrl+] for go to definition using LSP instead of ctags
vim.api.nvim_buf_set_option(buf, "formatexpr", "v:lua.vim.lsp.formatexpr()") -- Code formatting (gq etc) using LSP
Everything else one always sees with Neovim and LSP are other plugins like nvim-cmp or Telescope.
This isn't only good, though. Like you, when I don't use vim itself (or nvim nowadays) I use vim bindings in my IDE.
But since I do most of my typing in this environment, I've lost track of the number of times I've closed windows by mistake because I have ^w in muscle memory...
> Bullshit. Seriously, you probably have time to watch some junk content on YouTube or whatever
I get it, we could all produce more and do more to some effort, but really, why? Is the purpose of mankind to completely dominate the universe and know everything? I'm sure the author means well, but this rubs me the wrong way. Plenty of people who just live ordinary, only very modestly "productive" lives are plenty happy and neither you nor I are better than them if we do more shit like customize our text editors. When someone says they don't have the time they mean they prioritize other things more highly than that thing and it feels wrong to tell them their priorities are wrong by accusing them of lying about their available time.
I'm sure this comes off as overly sensitive and really I'm not that bothered by it, but I do think we as technical people can do better than I perceive us doing. Non-tech people seem to believe we're a very judgemental group and I can't say that I blame them.
> I'm sure the author means well, but this rubs me the wrong way
Me too.
I don't want to live running on the treadmill my whole life. Default human state is idle - all work comes from necessity, whether from hunger, cold, or some other, more sophisticated need.
The idea that "we can all do better, therefore we must" might seem noble from at first - striving for the perfection and whatnot - it's still an idea that mostly benefits those who benefit from our work and don't benefit from our idleness, whoever those people may be. And it is often used as an excuse to bully those who fail to meet such expectations.
I get what you are saying, and I agree. I am a believer in wu wei, and a long time vim user.
I agree the tough love to tone is a bit much, and harms the author's message.
The real message is that learning vim is like learning stenography after learning how to type. Many people don't want or need to do it, but people that know both can do things that others can't.
My guess is that the author may be presenting that tough love attitude because they had to tell themselves that to get over the comfortable rut for themselves.
Thanks for those comments, I really appreciate your feedback.
Let me explain what was on my mind when writing this paragraph. I feel like atm many of my University colleagues are working very ineffective and thus they actually don't have free time, or very little to say so. This is very depressing for some of them and I think that their coding effectiveness and often poor knowledge of shell, linux administration in general or other dev tools is the main bottleneck here. This comment was not about working more effective for the sake of it. It was about getting you more time to do stuff you want to do.
The way I see and usually use these kinds of things is not necessarily to get more done, but rather to remove annoyances.
I like vim because I don't have to mess around with cursor keys and remember whether the system I'm using expects me to press home, or fn+arrow, or the key in the left corner (ctrl) or the key next to the space bar (command) or the one in between (option – office for mac) to select a word text. It just gets out of my way and lets me enjoy what I'm doing.
I prefer a tiling window manager not because it allows me shave some milliseconds off window management, but because having to drag windows around is irritating to me. Bonus point for not having a different behavior if there is one or multiple open windows of the same application running.
The same with keyboards, I may type faster on a mechanical keyboard, but that's not why I use it. I use it because it feels better when I type on it. I don't have to make sure I press the keys exactly in the middle or else they may or may not get stuck in the middle and not register (cheap HP keyboard at work). Do I type faster? You bet. But cranking code faster isn't the reason.
I agree. Watching videos on YT is part of some people's free time (like for other people is going for hikes, cooking, doing a hobby, etc), we shouldn't be condescending about that.
It also begs the question, if I "have" to be learning about something productive, why Neovim? Why not Golang, Zim, the latest React plugin, etc
I think it’s more charitable to read it as “it’s not a good enough answer” — you have the time, you’ve just chosen not to spend it here. Perhaps you have a good reason for it, and perhaps you don’t, but if you default to “who has the time for such things” you’re not being honest about it (to yourself, or to your questioner).
It’s also only once you move on past that first nonsense answer that I can make my case: it’s worth spending your time on subject X, for reasons…
But if we never get there, you’ve just brushed off the person unfairly.
He did not say "Seriously, you probably have time to go for a junk hikes or cooking or whatever" - he talked about watching silly youtube videos which most people feel guilty about. I might choose to watch cute cats for 3 hours but I won't be proud of it.
I don't think there's anything condescending about that, it's probably an advice the author found genuinely helpful in the past as well (well, I did).
The way I think about it is that if you can spend 10 or 15 hours to learn your tools better, you can become more productive, often dramatically so.
And then it's up to you what you do with that. Maybe that means you push yourself and do more, and chase the raises and promotions. Or maybe it means you work a half hour less every day and still get the same amount of work done.
It's unfortunate that the knee-jerk reaction to a suggestion to master our tools is cynical.
I think we all should invest more of our time in improving ourselves and our productivity, because then we get to decide what to do with that, not our employers.
You're not wrong, the constant focus on "productivity" can be off putting.
For me, it's not about productivity. It's about how less frustrating the process is. You don't realize the base level of stress you have in your day to day life as a result of the unergonomic UX of your tools until you try something different. I wanted to learn vim like operation as a sort of academic experience, and now my computer just does what my mind wants it to do, very little friction. The hard part is convincing yourself to learn to do something a different way. Don't worry yourself with the productivity sales pitch, just do it out of curiosity and I'm almost certain, when you're done, you'll like it a lot better.
One project that seems super cool I hope continues on is helix. https://helix-editor.com/. I just started messing around with it but the selection -> action philosophy behind text manipulation feels much more intuitive to me even though I'm proficient with vim at this point.
I recently made the switch from vim to helix. It turns out that I don't really like screwing around with my vim config for hours and hours. Helix has great defaults (themes, LSP already installed, syntax highlighting already installed and enabled for popular languages) and that's made a huge difference for me.
My vim config was at least a hundred lines, and that's not counting the endless plugins. My helix config is three or four lines to set my theme persistently and disable auto-filling parens. Something like:
theme = "onedark"
[editor]
auto-pairs = false
And Helix doesn't even support plugins (yet), so this is all bundled with the default install.
I'm on the latest release because their was a copr available for Fedora. I haven't noticed any issues so far but have only used it for a couple hours at this point.
This may be a low effort reply, but I also started using helix recently and it has been absolutely wonderful. I haven't customized it at all yet and I have yet to find something that just doesn't make sense by default.
Definitely good to try different editors, but don't write off the OG editors.
There have many, many editors hoping to make vi and emacs obsolete, yet decades later they still are heavily used. Not true for some of the newer contenders --- time is a great filter.
I spent a few hours tonight going through https://neovimcraft.com looking for new nvim plugins. Every once in awhile I find something that's pretty useful. For example:
I'm certain I've accumulated 100's - if not 1000's - of hours customizing my editor since I started learning it 6 years ago (sorry I'm an Emacs user not Neovim) and I don't regret 1 hour of it.
I used to say that emacs was better than vim at everything except editing text files, but with undo-tree and evil-mode I have less and less of a reason to reach for vim.
This is something I’ve found very easy in vim with bufdo , windo, or populating the quickfix list (or args list) and using cfdo/cdo or argdo to be really specific about where the replace should happen (e.g. replace FOO with BAR only on lines containing STRING or in files containing STRING).
I've tried a lot of multiple file, find and replace solutions, and spectre is the one that seems to make the most sense to me. There's not much to it but it's very effective. Regex works the way that I expect and it's easy to toggle options on and off.
I have just installed it and it looks really neat, i usually switch back and forth between neovim and emacs (depending of the type of project), and use deadgrep and deadgrep-edit-mode for that but may as well use sometime nvim-spectre..
I've taken the dive very recently as well, not into vim directly, but into a text editor called Helix. It's similar to vim, except the main difference is that you select what you want to modify and then modify it (word-verb I believe it is called in vim parlance). I think this makes more intuitive sense than doing it the other way around.
I have a similar experience to the author. I did the tutor, wrote some notes as a cheat sheet, keep it open somewhere and just use the editor. I began using lots of tools that were keyboard focused and used vim-like keybinds (qutebrowser and other things). I wouldn't say productivity is increased, and I'm not a productivity zealot, but I'd say that once my mind adapts to the new environment, doing things is smooth as butter. The hard part is the fight inside yourself against the idea that you're relearning something you already can do another way that you don't actually need, afterwards you'll ask yourself why you ever did it the old way.
I love using neovim but switch over to vscode for debugging. I’ve heard of vimspector and other plugins that are similar but I’m curious to hear what debug workflows do people here have with neovim/vim.
Also, do you have any plugin recommendations for debugging?
I honestly wish no one used development debuggers. If your data structures and programs are so complex you need to have deep inspection the root of that problem is your complexity, not your tooling. Every pleasurable project I've been on has been a project where print statements were the best debugging tool, because the simplicity meant I could more quickly debug something with a quick print than a slow deep dive into some debugger tooling.
Granted, I get it, you didn't design the thing but you still need to debug it so no judgement, just more of an observation that if you limit yourself to simple tooling you might be surprised at how the pain points will force you to spend more time thinking about how to design your own code to be more simple and that's bound to have a far greater impact than any debugging tool could provide you.
I've found and fixed so many bugs that are simple to deal with using a debugger but would require hours of peppering the code with print statements to even get close to a solution. Some simple examples are deadlock bugs in multithreaded programs (easy to halt the program and see what thread is blocked on what) or uncaught exceptions from somewhere unexpected (set the debugger to break on throw).
With a debugger you can also change the behavior of a live program, e.g. modify variables or jump over a piece of code that would otherwise be executed.
Every person I've encountered professionally who either "doesn't use debuggers" or thinks "print statements are better" seems to be under the mistaken impression that all a debugger is good for is stepping through code.
Debuggers are fantastic tools. You should re-evaluate your view of debuggers and you will become a better programmer.
I can imagine someone who spends time around mostly engineers that are junior enough to not know what a debuggers fundamental capabilities are might assume that anyone against debuggers is simply ignorant. I can assure you, as someone who isn't so junior that I've weighed the costs and benefits and rest firmly on the side of being against them. The benefits are obvious, but my experience has been that over the course of my career I started noticing a pattern of debugger usage and overly complex code from the people who lean on them.
I'd have to support this as well. Many folks always reel in terror when I tell them I almost never use a debugger, or I'm using gdb or lldb instead of some graphical thing if I decide that it's worth actually running.
I think they have their place as tools but largely that's dwarfed by other practices. In the notion of systems thinking, I try to limit the scenarios where needing a debugger is seen as the natural extension. This means having tests, practicing type-driven design, mapping my APIs to some real-world model (and knowing where that fails or falls short), using languages that obviate the existence of certain classes of bugs (e.g. Rust, languages with a GC), etc.
Sometimes you're trying to inspect behaviour that changes in the moment, and debuggers do great there. However, I'll say that some of the most interesting bugs I've dealt with were only visible in release builds with no debug symbols, so my debugger didn't do much of anything for me there.
Plus, this doesn't even dig into other tools that _aren't_ taught because people reach for their debuggers. How many of the folks grabbing debuggers every day have been given the same speech / sentiment given to toolz above about strace? valgrind / address sanitizer? thread sanitizer? syslog?
I feel like this comment might be a bit rambly, but I was hoping to expound on what toolz mentioned above -- there's a lot of ways to crack an egg here and the debugger is something I almost never reach for.
Using print debugging/strace/valgrind/etc, you're looking at the evolution over time of particular components of program state. Using a debugger, you're looking at all components of program state at particular time slices. They enable different viewing angles. (https://mobile.twitter.com/ManishEarth/status/13870782220560...)
I personally find that both are good tools, but to know what you should be using, you need to think about which viewing angle you want to choose: which components of state do you want to inspect and which moments in time do you want to track? If the answer is "these specific state components/unknown" (e.g. "when is my program accessing invalid memory?"), that's where print debugging comes in, with specializations depending on which particular state components you're looking at (strace or eBPF for IO, valgrind for invalid memory accesses, etc.) If it's "unknown/these specific times" (e.g. "where is my program setting HTTP response headers when a request occurs?"), then a debugger is a good idea.
However, what you said does have truth to it. Good programming practices generally center around the management of program state* (using types, specifications, whatever). If your program is not designed well in those terms, then the more likely it is that you have no idea what state components you want to inspect, meaning you reach for a debugger first. And if it is designed well, you won't need a debugger nearly as often. But sometimes we have no choice, whether that's due to an inherently hard problem space or lots of bad code that we didn't write, so a debugger is necessary.
* I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)
> * I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)
There was a live, 3D, peer-to-peer interactive environment back in the early 2000s called Croquet that made use of the concept of "pseudo-time." It was built on top of Squeak Smalltalk (there are some decendants today, including croquet.io). The part that handled the time management in a way you might find interesting was called TeaTime [1], and built on the ideas of David Reed thesis about pseudo-time [2]. If you are not familiar with these you might want to check them out!
> But sometimes we have no choice, whether that's due to an inherently hard problem space or lots of bad code that we didn't write, so a debugger is necessary.
I don't disagree! The notion of state vs. time snapshots in terms of the mental model seems like it might be missing something small but sounds mostly on the mark? E.g. in dynamic languages my REPL is more of a debugger than any actual debugger could be.
> * I don't actually know if there are programming practices that center around managing moments in time. I can't even think how that would work, but I would be very interested to know if there are any :)
I think this depends on how you abstract control flow. Actor model comes to mind, as Smalltalk really doesn't have this notion of "time" in the same way. You debug live in such a system, and "time" is more a matter of what abstraction sent or received something (and as such may have failed). Similar arguments could be made for conditions / restarts in Lisp, perhaps even more strongly, since you can manage errors through conditions and then restart code (going back in time, so to speak) in a sort of live-debugging way. Not sure it measures quite to the degree you were asking, but that's the first thing that comes to mind.
Another thing is the movement towards async-await / cooperative coordination in programs. Even if you ignore concurrency, designing code in a way that coroutines cooperatively yield to one another (e.g. generators in Python) helps sort this out too. Basically, you make "time" in a program a function of control flow, and do that by forcing an abstraction where you explicitly yield control in the program. This relates to both the actor model and conditions / restarts in Lisp, so I feel like I'm pulling on the same train of thought there.
I use vimspector when I need a debugger, but find I don't reach for it nearly as often as I did in vscode. Nothing against those who are effective with it but I spent too much time crawling and not enough time solving. Print lines make me think more on what I really care about.
Vimspector isn't nearly as friendly as vscode but the which-key plugin jogs my memory on the key bindings pretty fast.
I mostly work with python and drop pdb into my code if I want to step through and see what’s going on. I run tests with the make command so I can use the quickfix list to skip between errors.
I like this post, it reminds me a lot of when I started using vim / neovim in university. I spent a lot of time learning nano, cramping my hands, and then eventually deciding to sit down and learn vi proper.
One thing I'm not so sure of though -- the justification for neovim seems to be partially due to needing a pretty recent version (at least newer than 0.5.0, for LSP features). There seems to be a big portion of vim users who seem to dump on neovim for one reason or another as some kind of meme, but I'm not sure that I agree about it being bloated or whatever. If I have to run Slack for work next to neovim / vim, I'm pretty sure I know what is using the majority of my system resources... Anyways, back to needing a recent version of neovim: I think the author could probably get by with just regular vim + extensions if they didn't use LSP stuff.
To be honest, I still haven't really used LSP much, and most of my experience using similar features in other products (Intellisense in Visual Studio, whatever the equivalent broken thing in Xcode is called) is that it really was never that useful? Maybe I'm misunderstanding something and it's just not good for me and my workflow, but I feel like a lot of newer devs seem to enable it and declare that they can't work with anything that doesn't support it. For a long time I've avoided such features since they often seem to have poor performance (Xcode's version of such has definitely taken down a Macbook Pro on me before), or just generally don't add much to the experience other than some coloured lines under parts of my code.
A good compiler (e.g. rustc) and corresponding linter for static analysis (e.g. cargo clippy) are actually pretty good on their own! This isn't true for every language out there, and maybe that's where LSPs are more useful - the Typescripts / Pythons / Javas of the world! I don't know if I'm over-simplifying it though. Either way, I'm pretty sure my point is that whether you choose vim or neovim, it's a great idea to sit down and spend a good chunk of time just getting better at using your tools. It's the kind of exponential improvement that won't even seem egregious a year down the line.
> To be honest, I still haven't really used LSP much, and most of my experience using similar features in other products (Intellisense in Visual Studio, whatever the equivalent broken thing in Xcode is called) is that it really was never that useful
It's useful especially when you're switching many languages, or working with new libraries.
Syntax error is immediately highlighted. Saves a context switch of changing to compiler tab and back to editor.
With every symbol, you can view documentation by hovering. When autocompleting also, a small window/popup shows docs for currently selected symbol.
You have automated refactoring available in-place, especially renaming. In most LSP it renames across all files and modules.
Granted it's not that useful if you're in-and-out familiar with the stack you're working on. But once in a while you still need to switch languages and use new libraries it will be useful.
Yeah, I think that's something that folks tell me all the time as well. I'm pretty consistently in Rust, C++, Python, or Scheme myself. I tend to only keep ~2 of those in my head at a time, but I don't jump around so often in such detail that anything like that would matter. And C++, Rust, and Scheme all have pretty good compiler and linter tooling that prevent me from really needing something extra. C++ may be the exception there (cmake can be a pain depending on your unit test framework) but even then I don't often find myself wanting.
I do think if folks find LSPs useful they should keep using them. I might even be convinced one day! But at the moment I find I'd rather not. Vim's default auto-complete functionality is actually fine enough for me most of the time, so I might actually be weird here.
You can get lsp support with vim. I have a set up for that. The best part for me with neovim is that I can run a server and open things up as tabs from other parts of my tmux session by pointing at the remote server.
I have a file browser (ranger) with a preview pane set up, I can select logs on a remote server and open the tmux select buffer as a new tab, I can pipe or redirect output into a tab.
It really brings my tmux terminal workflow into one cohesive system.
I can do everything else with vim that I can do with neovim, completion, linting, formating though a lot of that is either in a tmux pane below or pulled in as a shell command at the vim prompt. (though I'm probably not as hard core as some who do more with neovim)
Interesting! I actually didn't know this - I've stuck to neovim lately because GUI support is somewhat better than gvim on Wayland (which I think is really just about qt more than anything, but I never really used gvim-qt).
But yeah, tmux & vim together definitely changed a lot of my workflow when I'm not at my local machine. Now working away from "the office" is just a matter of ssh-ing into my machine and jumping into tmux.
I do keep a pretty spartan config though, so I imagine I could do most of what I do in regular vim as well. ¯\_(ツ)_/¯
I do as well, I have about 10 key binds and a couple functions for using tabs, and a couple plugins for linters/language servers which I can do without.
I have in my past done quite a bit of work out on prod hosts with vim so I don't like to get too out there from stock.
everything works in vim with the exception of the server:
Thats about it. I guess you have to have nvr installed. Other than that, I have a pretty sparse config all around.
I do a similar thing where I set a global nvim_listen_address variable when I log in and I can use that to pipe to a different editor for things like logs and such. I don't generally want my ops work opening a bunch of tabs in my coding window but I could set it globally and use the single editor if I wanted to.
That sounds amazing; as a neovim/tmux/ssh user already, can you point me in the right direction to get this? Just search "neovim lsp" and follow tutorials until I grok it?
> most of my experience using similar features in other products (Intellisense in Visual Studio, whatever the equivalent broken thing in Xcode is called) is that it really was never that useful?
No, they are not useful
I have been using IDE for sometimes, none of the features helped me to solve very complex logic in the codebase. I have to debug, test and trace the errors manually
And those who often refactor their code (with their IDE), I don't know if they are designing the architecture correctly. Once in a while is fine, but if they are doing too much of that, yea probably they are messing up the codebase. I don't really want to work with somebody like this, imagine that you have to solve the errors that they produce and IDE doesn't actually help at all
Vim is great, and it's great to see the author spend time customising a tool that he spends most of his time using. But is vs code that bad at keyboard-only navigations? I spent much less time customising the settings and can do 99% of my tasks without reaching for a mouse. The remaining 1% are for some extensions like the Postgres explorer, which I could easily mitigate by switching to a terminal and run psql, but I don't feel like reaching for my mouse occasionally is a big waste of time
Every time I come across posts like this it's inevitably:
- plain lies about IDEs, followed by
- painstakingly recreating half-baked partly-working parts of what IDEs give you out of the box
> I feel like moving your hand from the keyboard to the mouse every time you want to move the cursor a few words back or forth
This interaction is literally built into your OS. It's called navigating with cursor keys and modifiers (Option on Mac, Ctrl on Windows, etc.)
> to create a new file
Even if there's no direct shortcut (such as Cmd+N/Ctrl+N), all menu items are available from keyboard.
Moreover, you rarely create just a file. An IDE's "Create New" tools usually give you a plethora of choices to create a file and all the necessary boilerplate in one go
> split the window or whatever
This I can agree with, and I think I even reported this as a request for improvement to JetBrains.
> Searching for some cool plugins and tweaking them was a very cheerful time and I run into almost no problems during the whole process. And, to be honest, 20 hours for creating a virtually full IDE from scratch customized entirely for your personal needs does not seem that much time at all. Lua is an easy and pretty language for configuration code, I think I’ve learnt it pretty well just by reading plugins’ code
No mention of plugins or what they do. Random screenshot shows something a modern IDE has out of the box.
In vim specifically, there are many more powerful and precise movements you can make by chaining motions. But before those can feel natural and fast, you have to keep your hands on home row.
Feels natural to me when I 20<Up>. Homerow-ing is pretty distinct from vimops. I agree that it is faster than piano-typing, but it doesn’t add a huge sector into the pie chart of fast editing methods.
I don't know about you, but unless I'm actively typing, my hands aren't on the keyboard. And if I am typing, I'm in insert mode and the keys are useless then, but the arrow keys aren't.
I still remember this one time, 15 years ago, where I spend literally the whole night configuring my .vimrc, reading the :help pages for all of the configuring options, doing the tutorials, and just moving around and getting comfortable with it.
At 8PM that night I didn't know Vim, but by 6AM the next morning I was very productive in it. I'd say about 80% of my productiveness with Vim was achieved that night, and I could never change to a non-Vi editor since.