They are both useful. I'm a frequent committer but find myself using this, I wanna say, 0 - 3 times per month. It's one of those things that when you want it, you're really glad it exists.
Undo is something that's extremely useful after the fact - commits can accomplish the same end if you're fastidious about continuously committing but fall short if you only realize your need after you've made the edit.
I thought so too, it's a part I've always struggled with effectively using, cause I get lost so quickly so was happy for a moment. But then reading the comments first, I got disappointed before I even had a chance to open the article.
I find it impossible to use without a plugin. I use https://github.com/mbbill/undotree and map it to `U` since I realized I never use `U` and it's easy to remember. https://github.com/sjl/gundo.vim/ is also popular but I like that the former is in pure vimscript (and the interface is a lil' better IMO).
That's where pair programming came in but it turns out that most people hate each other so much that they'd rather work with a machine pretending to be a person.
I realize there are many levels to this claim but I'm not being sarcastic at all here.
Not really, LLMs do not push back on design decisions and will happy continue with whatever prompt you throw at them. That’s after we look past quality isssues.
It could push back more, true. Although it's role in pair programming is the driver, you are the navigator. I often begin a session with exploring and asking it questions of the code as I would a junior developer.
Not sure how to respond to this as clearly that's what I was getting at. Perhaps this is a response from an LLM though. Again, not being sarcastic, it just seems like it's maybe the case?
you make a good point and everything but have you considered the way people using LLM is similar to the way we review code together as humans? but if you think about it, they just swapped one of the humans with an LLM
Pair programming is exhausting to a lot of people, myself included. My brain just doesn't work like that. I work in fits and starts, with weird, sustained bursts of productivity.
It's exhausting to me too! But when you do it every day you get used to it. You also get a lot more done so last time I did it we would work shorter days.
I like to agree as sorta yes but also really no because it's a rubber ducky that doesn't give you the chance to come to your own conclusion and even if it does it has you questioning it.
Yeah, this. Every conversation inevitably ends with "you're absolutely right!" The number of "you're absolutely right"s per session is roughly how I measure model performance (inverse correlation).
Even though it means I probably wouldn't have a job, I think about this a lot and agree that it should. Nowadays suggesting programmers should be highly knowledgeable at what they do will get you called a gatekeeper.
While it is literally gatekeeping, it's necessary. Doctors, architects, lawyers should be gatekept.
I used to work on industrial lifting crane simulation software. People used it to plan out how to perform big lift jobs to make sure they were safe. Literal, "if we fuck this up, people could die" levels of responsibility. All the qualification I had was my BS in CS and two years of experience. It was lucky circumstance that I was actually quiet good at math and physics to be able to discover that there were major errors in the physics model.
Not every programmer is going to encounter issues like that, but also, neither can we predict where things will end up. Not every lawyer is going to be a criminal defense lawyer. Not every doctor is going to be a brain surgeon. Not every architect is going to design skyscrapers. But they all do work that needs to be warranteed in some way.
We're already seeing people getting killed because of AI. Brian in middle management "getting to code again" is not a good enough reason.
> While it is literally gatekeeping, it's necessary. Doctors, architects, lawyers should be gatekept.
That was exactly my point. It's one of those things where deliberately use a word that is technically correct in a context where it doesn't, or shouldn't, hold true. Does this mean I want to stop people from "vibe coding" flappy bird. No, of course not, but as per your original comment yes, there should be stricter regulations when it comes to hiring.
XDG was added somewhat quietly almost two years ago now. It was announced on www.vim.org but that was it as far as I know. They don't keep news that far back but here's the commit: https://github.com/vim/vim/commit/c9df1fb35
Bram started giving 100% after getting hired full time by Google, I believe, which continued on. There is an update on the Vim homepage now about it stopping, though I find the wording a bit confusing... I think they are dissolving the charity but still sending donations to Uganda? I feel a bit dumb for not understanding it but you can read the update on https://www.vim.org/. Unfortunately they don't have target links for dates, it's the [2025-10-28] update.
There is also Learn VimScript the Hard Way, which is of course a bit outdated, but it does help to know "legacy" vimscript. vim9script is very intuitive and easy to learn for anyone who knows any OO language from the past 30 years. The difficulty comes in learning the ins and outs of Vim itself (when it comes to scripting it, that is).
I love vim9script and write most of my plugins in it now unless I want something to work in the other vim as well, of course. Really happy to see it evolving and I'm particularly happy that tuple support has landed!
reply