I use these features more when doing non programming tasks. Often I could use find/replace and some regex. However I enjoy the experience of having the editor do some of the lifting. I don't think I'm faster or better for it, just a little happier.
Agree. Getting good at vim isn't something I do for my boss or my company, it's something I do for me.
Using something like "ci(" to blank the parentheses under my cursor and immediately start typing a replacement saves me, like... a couple of seconds. But it gives me a little dopamine hit that I think helps with job satisfaction.
> However I enjoy the experience of having the editor do some of the lifting.
Yeah, same. I recently realized that I use vim‘s normal mode features even in situations where I’d certainly be faster just typing things out manually, just because it feels good to “work smart”. Even if it’s not really.
Another downside: using (and watching people use) editors without vim features becomes painful.
> I have never been a power editor user; typing just never felt like a bottleneck worth fighting over (unlike exploration). It is interesting watching my kids get excited as they discover various Sublime Text features that I never use.
"I have never been a power editor user; typing just never felt like a bottleneck worth fighting over (unlike exploration). It is interesting watching my kids get excited as they discover various Sublime Text features that I never use."
and
"I am talking about generic text editing features; I definitely find language/IDE features like intellisense very valuable, and, as someone else mentioned, a good integrated debugger is among the most important things.
"
Typing for a programmer is like brake pedal technique for an F1 driver. Yes, it is important to be able to type effectively. No, it is not sufficient for being a good programmer.
It's easy to get lost in fancy editing techniques that get you a win of minutes per day (as Carmack mentions), while learning to come up with a better design will save you weeks in overall development time. Learning more editor shortcuts is much easier and more flashy, of course.
I completely agree - optimising tooling is converging on a local maximum.
Past a certain point the returns are rapidly diminishing and you burn a lot of time and effort on very marginal gains that would be much better invested on bigger picture, higher impact stuff - namely, the actual thing you're building. I wrote a blog post on this that you may enjoy [0]. I like your F1 analogy, I used tennis :-)
I don't think the comparison fits. You can be a slow typist and still a great programmer but you probably can't be a good driver if you are bad at brake technique.
Of the programmers I have known that are also super high speed typists and focus on typing (coding) speed, they also tend to write the most code. Voluminous radiant bouquets woven with crystalline class hierarchies, layers of unit tests that would give string theorists a bow to play a multidimensional symphony with. Prototype in your head, then on paper, then in a dynamic language (Scheme, Python, Lua), then a PoC in your statically typed language (Rust, F#). If your prototype is 1kloc and your editor has a modicum of refactoring support, you don't need much else.
Seems like a very wrong conclusion, like managers trying to measure programmer productivity by counting lines of code produced.
I would say speed of typing and amount of code produced have no relationship to the quality of the programmer. Of cause there might be exceptions if people was trying to type with one finger at a time and other wierd things but above basic typing skills I cant see how it matters.
I've been using vim/vi for decades, and am constantly referred to as the 'vim guru' in my dev sphere - but I only know like, 5 basic things - editing/navigation, search/replace, window management, cscope integration and .. Termdebug. The magic, though, is knowing how to access the command history window .. for some reason this always gets oohs and aahs.
For me, Termdebug is the killer feature. There's something about being able to debug things faster than the other IDE-using folks, who are usually just waiting for the spin-up of their IDE into debug mode to stop by the time I've already stepped through the code in focus ..
I think a lot of people would be in the vim camp if they could just master the 5 basic operations they'd need to use vim. Its pretty interesting to discover the whole world of stuff in help.txt that I just never, ever touch, for whatever reason ..
VimGdb/clewn .. but I don't remember having as good a time with debugging in vim until Termdebug came along, and mostly just had another terminal for gdb when needed.
Its a matter of switching between Vim windows rather than (in my case) Terminator windows - not that much of a difference to be honest, but the code navigation and completion within Termdebug is pretty dope - using it within vim means access to the compiledb navigation functionality ..
I know enough vim to get around, edit, and search/replace. I put in the original effort so I could edit files on any unix server I ended up on. I also like the modal editing concept.
But, even though I bring vim keybindings to all my local editors, my day to day is still a mix of vim + mouse navigation (and cmd+t obviously). I have never felt hindered by not being all vim.
I do touch type though, and have known programmers who hunt and peck with their index fingers. Not being able to type nowadays always seemed odd to me since, I just assumed people would learn to type better by being at the computer all day.
You don't get strain injuries if you hunt and peck. Being on the home row all the time is very un-ergonomic, depending on the size and shape of the hands.
If you have broad shoulders and long arms, finding a good posture is even more difficult.
> I just assumed people would learn to type better by being at the computer all day
I've noticed that with doctors. Maybe it's just where I live, but most doctors I've met hunt and peck. It's painful to watch them struggling to type their prescriptions. Considering how valuable their time is, it's a shame they don't spend time learning this skill.
Not sure I agree. I've been paying for a personal license of Visual Assist for a few years now. The power editing features I'm getting from it are really good, save me a lot of time. The "rename identifier" feature alone justifies the cost for me.
There’s some overlap - like option + up/down in intellij. Wouldn’t work without some parsing, yet basically editing text. Super powerful and personally probably most used feature.
In JavaScript, I often had to solve bugs and traced logic through 40+ source files. The reason I learned some editor power features was just to be able to navigate files quickly. For continuity of thought, I found it valuable
Flip side of this is that being a power cli user in 2020 is more powerful than ever before! Recently saw an interactive quantum circuit visualizer in 100% text mode. And its getting me personally back into old school favs like lynx, irssi ;)
> Yes, it can be very impressive watching people using the power tools to maximum advantage, and sometimes is can be a dramatic win, but I usually think that it adds up to... a few minutes saved a day?
I think measuring the gains of text editing features in terms of time is a distraction. Expressive editing features take something tedious and make it effortless. It makes it easy to do something that I'd normally put off.
But the reason text editing features end up not being that important is that if the task is mission critical, you'll end up just soldiering through, even if it's tedious. Therefore it's an incremental benefit not a revolutionary one.
I like text editing features because I personally like being organized, not because I feel like it makes me a more effective programmer. It lets me indulge myself in keeping code organized without that becoming a time sink.
This is very similar to how I look at it. Expressive editing features do not have a direct impact on my productivity when coding.
However, for those 1-2 hour focused coding sessions, it is easer for me to enter and stay in flow when I feel a better connection to my tools. Since I do perhaps a dozen of those a week, I am able to accomplish more and do it more enjoyably, even if I only spend 20% of my work time in one of those sessions.
I am not sure exactly how much the productivity increase is because I haven't tested it rigorously (honestly not sure how to even measure that), but I'd guess it's still only 5% at most. The benefits to my happiness and fulfillment when coding are definitely noticeable though, and I think it is because I am able to spend more time in flow.
Edit: and for what it's worth, there are things that arguably have much greater impact on my ability to stay in flow than just the text editor: how good the debugger/REPL is, my familiarity with the language and libraries related to what I'm doing, etc.
Few minutes gain is simply not true. Its IMO closer to an hour. Having ability to jump asap to any letter on the screen and any file in the project in few keypresses without browsing trough the tree and son on, is massive speed up. It doesn't just save time, it saves focus.
This 100% -> Few minutes gain is simply not true. Its IMO closer to an hour. Having ability to jump asap to any letter on the screen and any file in the project in few keypresses without browsing trough the tree and son on, is massive speed up. It doesn't just save time, it saves focus.
*
would argue that a lot of people who write things like 'it only saves a few minutes a day' have never actually tracked how much time it actually saves
*
one good thing worth doing is to get a tool that tracks how much time you spend on different applications and websites during your work day
it will TRANSFORM your understanding of how you use your time
Some of them are, most of them are not - you cant really jump to ANY letter on screen without vim plugin (AFAIK).
Having quick access to options is paramount - like vscode F1.
Besides, huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs, even if the feature exists. Its the IDE mindset (personal experience).
> you cant really jump to ANY letter on screen without vim plugin
There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.
> huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs
Does it count if you "browse the GUI" without ever touching the mouse?
I use the "search everywhere" [1] dialog in JetBrains by pressing double-shift all the time. When I used emacs, I would M-x tab-complete commands all the time. Same thing.
Which requires more effort: pressing 4-ish keys to spell out an editor command you use only a few times a day or trying to memorize every arcane key combination?
Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.
I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time. Everything is keyboard accessible nowadays, and I would argue vastly more discoverable compared to vi/emacs.
I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.
I used vim for more then 5 years then switched to VSCode as it makes plugin setup much easier. I also use VS and JetBrains here and there and maybe I am biased, but I prefer code at this point.
Yeah, modern IDEs got some stuff from modern editors for sure. One of the primary pain points for me is that installation/setup of IDE is much more lengthy, they are pricey too - I can setup vim/code in minutes on empty machine. Just downloading/installing VS takes a bunch of time. This however has nothing to do with efficiency but counts overall.
> There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.
The page you posted lists InteliJ Platform. Vim doesn't have such plugin OTB FYI.
> Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.
If tabbing is done via mouse, yes.
> Does it count if you "browse the GUI" without ever touching the mouse?
Ofc not, I prefer to have a GUI, I just don't think analog controller like mouse is good way to interact with it.
> I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.
That might have been a real thing when people did things on servers directly etc. Today there is almost 0 need to do so.
> I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.
There's nothing magical about it.
I prefer text based interfaces whenever available as they are generally more responsive, light on resources, use less network bandwidth, and are inherently compatible with SSH. They also tend to be very minimal, having far fewer extraneous features (ie fiddly distractions) due to the inherent design constraints.
If one isn't available though then I'm happy to use a modern GUI (my web browser is an example). In fact, GUIs consistently seem to be more newbie friendly so if it's a one off I might actually avoid a text based interface just to save time.
> I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time.
Watch as my eyes roll out of my head, onto the floor, and then out the door.
Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?
The worst part is that most vi/emacs users actually DO have experience in both environments, whereas most of the people who want to claim vi/emacs isn't any faster don't. Yet they want to present themselves as an authority.
And I'm one of the people who refuse to use vim emulators in IDE's because they're never quite right (and never integrate well with the IDE).
> Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?
Anecdotal, personal experience, including seeing constant outright incorrect claims about graphical IDEs in threads like these.
The claims usually take the form of: "I use vi/emacs because I can do xyz using only the keyboard" - where xyz is something that most IDEs maybe couldn't do 15+ years ago, but which they all can do today.
It's not generally that people are saying it's impossible to do in an IDE, just that it's slower to do, and generally more awkward.
Just the other day on reddit I was having this "discussion" with someone, in which they claimed that because they have "find in files" in their IDE it's equivalent to vim `grep -iRl whatever`.
In reality I'm going to do what you're trying to do in a fraction of the time. IDE's have their advantages, but speed is not one of them.
I'm probably a vim power user, but I stopped adding to my knowledge years ago because nothing seemed to be adding to my productivity. It sounds like Carmack just hit that point earlier.
I feel this way about version control systems. More trouble than they are worth to me, even when working in the same tree with many others. If I make a branch, it's only because that's the only way to submit a PR. Merge conflict? I'll look at my diff and apply it manually to the other side. Merkle trees are great, but the only useful history to me is a straight line!
I find Sublimes "power" features really useful for the tangential stuff. Getting a good look at a JSON object, preparing some mock data, preparing one-off data. Basically everything that falls before the threshold of being worth automating or writing a script for. With multi-line edit and a couple of plugins you can do some "excel" like stuff without the overhead and with the simplicity that plain text brings.
I am a long-time Emacs user. Occasionally, editing/macros/etc can save a LOT of time, and makes it much easier to make some changes which I might not decide to do.
What I find more important however is the effective window/buffer management. Being able to manage my screen real-estate is killer; being able to do everything within one "world" is really valuable. One of the things I find most valuable is that I run my shell within Emacs. This lets me keep my flow going instead of switching context and perhaps getting distracted. I can watch the output of tests etc in one corner of my screen and edit files etc in the other ones. And because its quick to switch buffers, I can more easily reference various files for what I am doing.
Basically, the literal time it takes to type is not the big benefit, but that it allows me to reduce my cognitive overhead of doing everyday, boring things like resizing windows, looking up symbols/finding definitions etc. This makes it easier to focus on my task at hand and not get distracted by all of the mundane tasks I would need to do otherwise.
> What I find more important however is the effective window/buffer management.
Yes! I cannot imagine how my life looked before `C-x b` (switch buffers in helm).
However, I still have an actual terminal emulator open the entire time for serious stuff. Eshell is not compatible with a lot of programs, term/ansiterm are ok but not quite as good as a dedicated terminal.
I get around having to context switch by using virtual desktops (KDE). I have Shift-F1 bound to the desktop with only emacs, and Shift-F3 to my terminal. Works beautifully.
Rather than try to use a terminal in emacs I've found it more useful to use an solution designed for emacs, i.e git vs magit.
Eshell is a really great shell and a lot of full screen nurses apps can be replaced with an Emacs equivalent. The ability to use elisp in pipes and stuff is a game changer
Sure, so basically I keep a small eshell window at the bottom of my current frame at all times. Full screen commands like man, info, or less will automatically open a new Emacs buffer. You can seamlessly mix and match shell constructs and elisp, allowing you to leverage elisp and traditional shell scripting together. It also makes it really easy to open a file from eshell since you're already in Emacs. Instead of things like top, I just use Emacs process viewer.
For full screen apps that absolutely have no Emacs equivalent (quite rare), I have a term buffer that I occasionally use.
You should check out a list of eshell features, its much more powerful than even zsh.
Also I use company-mode for command and file completion, which is a lot nicer than zsh 's completion method, for example. Once you get used eshell, it's hard to go back.
I think you should be able to use eshell+Emacs for almost everything, and for me at least, I find the experience quite nice.
I used both of those for years but recently switched to vterm. I highly recommend it.
I do keep a terminal open for a variety of reasons (and some curses apps don’t work perfectly in emacs) but I probably only use it every other work day.
Yeah you can emulate this behavior in other ways. You could also use vim splits, a tiling window manager for some of it, etc.
That’s fine. I would probably argue that it’s easier to get there with emacs, and having one language is a lot nicer than having to learn vimscript, whatever tmux uses, etc, though neovim makes that a totally different discussion because iiuc you can script with many different languages, and emacs lisp, while pretty decent, isn’t great.
Probably the biggest issue facing these environments at this point is that need stronger types to scale better. Doom emacs helps with this because it locks packages down, but for example spacemacs was always broken for me. So eventually I switched.
Anyway if you want to try it I’d recommend doom emacs. It uses vim style bindings so your muscle memory won’t atrophy
My first real editor was microemacs on Amiga. Just thinking about it puts a smile on my face :) I learned C and became really good at it with that editor and didn't need to change a single setting or learn a complex keyboard shortcut.
I am slow typist and really lazy at exploring all the possibilities of modern text editors/IDEs. Well except of intellisense which I consider absolutely invaluable. Still I do not feel it ever held me back when programming.
When people tell me stories about $EDITOR significantly improving their productivity, I wonder what kind of sweatshop coding they do where typing speed is a bottleneck...
I used to have a pretty nice emacs setup but this year I have been coding python in gedit (notepad.exe of Linux) and I've done just fine.
It's probably the same people who spend a week configuring their desktop, only to have it covered up by other windows 99.9% of time. Some people simply like it.
I’ve tried to force myself to pick up vim a few times but after getting a bit older I realized that I don’t want to become one with my machine as a fighter pilot might be with their plane. I like the distance the mouse move and click provides me. I do more thinking and reading than typing anyways
The reason to pick up vim is ubiquity, not efficiency. And you REALLY don't need to know much. Maybe half of what's in the vimtutor tutorial is enough. Personally, I'd also suggest at least learning how to do search/search & replace with regex which is easy too (and bonus, has high affinity with sed.)
That seems like the most any modern developer/*nix user should need to concern themselves with vim and wholly for the reason I mention above: it's the most likely text editor to be there on unix-like systems.
Editing text on servers by hand is not necessarily a practice you want to invest in. Even if you are not on the immutable infrastructure / containers / cloud bandwagon... Puppet is 15 years old now. CFEngine is 27.
It's 2020, dude. No one sysadmins individual boxes anymore, it's all infrastructure-as-code. Which means if you have a problem with your server infrastructure, you shoot those cattle and provision new cattle with the CFT you wrote in Visual Studio Code.
I picked up vim decades ago and I’m glad I did. I don’t feel “one with the machine” any more than I feel “one with the paper” when I use a nice pen. I feel like the machine is getting out of the way.
In a strange way, Vim might be for you then. I've used it steadily for the last decade as my IDE, and I have a minimal set of plugins and an unimpressive .vimrc. I've put most effort into setting up very limited, low-key syntax colouring schemes; and linting. To me now, Vim (well, neovim) feels like the bare tool with a few ornaments I keep around, and little more; switching to VS Code occasionally feels like going into a circus. Vim is effectively my distraction free coding environment.
Something people often forget to consider when they talk about all the benefits of being an editor power user: how often they get distracted or go down rabbit holes when tweaking editor config or using advanced features. I've worked with people who seem to spend half their day on this stuff.
So while it can certainly be impressive to watch someone who has mastered their editor, I always secretly kind of doubt that it's really much of a productivity win for this reason.
I think there are huge wins for getting proficient with your editor (refactoring commands, debugger, etc. as John Carmack mentions), but sharply diminishing returns beyond that.
> how often they get distracted or go down rabbit holes when tweaking editor config or using advanced features. I've worked with people who seem to spend half their day on this stuff.
> So while it can certainly be impressive to watch someone who has mastered their editor
I'd say anyone who spends a significant amount of time tweaking their editor while they should be working, outside of (infrequent) setup periods, has not mastered their editor (or is just slacking off). The entire point of setting this up is to make you more efficient.
So should you write a short script, or build a tool, or write a macro for your editor to do some repetitive thing or just do it manually for now (and therefore always in future).
Same thing goes with having a pipeline of transforming data from one format to another. Do you use a simple ad-hoc method where you just use features in the tools (Text filtering + Import to Excel + Manually creating graphs), or do you write scripts to automate part or all of the process?
When should you stop doing things manually and automate them instead?
> When should you stop doing things manually and automate them instead?
When your best estimate is that spending the time to automate it will be a net benefit in the long run. (https://xkcd.com/1205/) This is hardly unique to configuring an editor or IDE though.
If someone is repeatedly and consistently spending "half their day" configuring their editor then either they don't really know how to use it, or they're slacking off, or they consistently make bad time estimates (https://xkcd.com/1319/), or you don't actually understand what it is they're doing and why.
I find being good at vim makes exploration much easier though. Being able to use Ag to populate a quick fix list is way faster for me than ctrl-f plus clicking through every option. And being able to go up and down the movement stack let's me retrace how I navigated to where I am right now, in a way that isn't possible in many editors. Tools like just searching through open buffers let me use search in large codebases without having to wait forever for results. So for me being good at an editor is more than just being able to make fast edits (although that's definitely a benefit too).
And even if I only saved a few minutes a day, over several years that is a lot of time saved, without much investment. It's really easy to get started with vim, get comfortable with the basics in an hour or two, and then just get better by using it every day. Then you can slowly introduce features that save you time. Just setting up fzf and ag has probably saved me several minutes a day vs. using vscode search.
I think arguments about productivity miss the point and Carmack is actually right that typing speed isn't the bottleneck.
I think the reason programmers love to tinker with their vim or emacs configs is because it's simply satisfying. Just like a blacksmith has their very own set of valued tools, there's something extremely rewarding about configuring your setup just the way you want it. You work your entire life with it, so you might just as well make it your own, I think that's what people get out of it, just a subjective sense of making things fit right.
It's like my barber who has some cool vintage scissors he got from someone. Could he cut my hair with some high grade scissors he bought on the internet? Sure, but he likes his ones better. At the end of the day programming is more like a craft than a science and it shows when it comes to topics like this.
For me at least it's more than "simply satisfying". It gets the UI out of the way. It's removing a number of mild distractions and nuisances that are otherwise there all the time.
It's not about typing speed at all (for me). It's about having a clean and orderly working environment where the number of frustrations have been minimized.
On the other hand it's typically quite easy to customize the UI of IDEs and hide menus and such to the point that it's possible to tune out whatever is left.
Therefore I'm tempted to look at this problem not from a technical but rather from a social perspective: I consider this preoccupation with editors as a kind of fixation and way of exercising power in a straightforward way as a part of an increasingly complex and unfriendly environment. We can't customize the stupid Scrum processes guiding our lives, can't customize the management which often is rather clueless about what we're doing, can't avoid that most software projects are ultimately pointless even if they claim they're changing the world and empowering users. But we can certainly customize our editors.
And then there's the social pressure from the typical hacker circles which would happily dictate what programming languages, tools and paradigms are good and which are bad. Of course this scaffolding all comes crashing down when one looks at the results and there's no discernible difference between the quality or success of projects where various editors or processes or languages are used. So the focus moves to personal benefits, personal preferences and programming as craft and so on.
But it's all just a game programmers play, isn't it?
> customize the UI of IDEs and hide menus and such
That's not even half of it. TUI programs are designed to be keyboard driven from the start, not as an afterthought. All the IDEs I'm aware of are hopelessly outclassed here. There's also things like registers, column editing, and the buffer abstraction which make common tasks less cumbersome. The list continues.
It's not that one tool can be used for a task that the other can't; rather it's just better at it from my perspective (given my particular workflow and toolchain). For me, there's a significant ergonomic difference which makes for a more pleasant process overall.
Is keeping a clean and orderly workspace "just a game"? What about using the best (from your perspective) tool for the job? I imagine different people will care about these things to different degrees.
As you point out, perhaps for some there's primarily another motive (exercise control, irritate a coworker, maintain an appearance, ...). That's not mutually exclusive though and it's hardly unique to programming.
I think there’s more to it than that. Yes, it can be very satisfying to tinker with one’s tools rather than getting work done. But that doesn’t explain someone like me who took the time to learn vi (not vim) rather than using a basic text editor like nano or Notepad or TextEdit.
So why would I take the time to learn vi? I don’t tinker with it (beyond adjusting a few basic settings like autoindent, line numbers, incremental search, etc). It certainly took me a long time to get very proficient with vi. It’s also the case that any editing task I can do with vi can be done in any other text editor (they’re all “text equivalent”).
The answer is that vi, more than any other editing method, removes friction from the editing process. Having used it for a long time, I’ve built up muscle memory that allows me to rapidly jump around files and make precise edits. It also lets me easily automate repetitive editing tasks with its ex commands, macros, and of course the humble ‘.’ command. In the case of more elaborate tasks such as paragraph formatting, table formatting, or inserting line numbers into the text, vi lets me easily pipe motions, ranges, or buffers through shell commands.
So why doesn’t everyone use vi? Well that’s specific to personal taste. Some people don’t get as frustrated by friction in the editing process as I do. Maybe John Carmack doesn’t mind reaching over to grab the mouse in order to move the editing cursor somewhere else, or to select text for copy and paste. I don’t know what his editing environment and workflow look like. Perhaps he uses some other editor like vi but with the default configuration.
I guess there’s one more piece to clear up and that’s the question of whether or not I qualify as a “power editor user”. I think I do. I don’t tinker with my editor to the incredible extent that some others do, for sure. I used to tinker and found it a deep rabbit hole of distraction which inevitably led me to a slow and complicated environment (highly customized vim) that really didn’t do anything fundamentally faster/better than I could already do in plain vi. Having said that, I think my experience with vi (including having purchased and read O’Reilly’s book on the topic [1]) has helped me to master its commands far more thoroughly than a typical vim user. So I think that qualifies me as a power editor user. Others may disagree.
"I think the reason programmers love to tinker with their vim or emacs configs is because it's simply satisfying."
I spent a ton (no, really a metric ton) of time tweaking my vim and emacs configs, and have thousands of lines of code in each, but I haven't touched either in years, and I'm pretty happy with that.
Yes, tweaking editor configs is fun, but I have other interests too, and those other interests have taken priority for a long time now.
Incidentally, I consider all that time tweaking my configs very well spent -- not because it was fun, but because my editors are enormously useful to me now, and I wouldn't dream of ever going back to more primitive editor.
I actually pick type. I'm pretty fast and I can do it without looking at the keyboard. Although I can't switch keyboards easily and I buy multiple of the same keyboards at a time because of this. I've found it doesn't hold me back compared to touch typers. Data entry speed is just not the bottleneck. On my best day I might write between 500-1000 lines of code, which is just not that much typing spread over 8-12 hours. Average days are adding/modifying maybe 200 lines. Typing or editing speed here just really isn't the issue.
I personally don't think it's particularly rewarding, I hate touching my vim config. But I still use it because, while typing is definitely not a bottleneck, it is still something I'd otherwise need to actively think about. Vim lets me compose the concepts I use when thinking about the language, like parameters, blocks, tags, lines with editing operations directly. Deleting a block (dab) becomes just that, from muscle memory with no mental translation to concepts like backspace or selections required. I'm sure with enough practice you can get really fast at that too, but I don't think the amount of mental effort and context switching can be as low.
When I used Keyboard and Mouse combo, I suffered from crippling wrist pain. I stopped getting this when I shifted to VIM - use VIM editing in every IDE and application now.
I agree, in general, with his point. But multiline editing was a real game changer for me. Things I once did manually that can be achieved with significantly less tedium.
How do you use it? I’m terrible at using these sorts of features. I occasionally try again but often find it awkward and not much of a win over my normal method that doesn’t involve multiple cursors. I figure either I’m doing something wrong or just not coming up against the right cases.
Definitely courses for horses, and all that. Whichever way works quickly and accurately for you is the best way...
I've used multiple cursors for many purposes, initially as a dev it worked very well as a poor man's ETL - take a spreadsheet and perform a bunch of transformations (reverse first name and last name, trim these fields, add leading zeros to this field, concatenate these fields, delete this field, use some sublime plugins to generate incrementing IDs, etc.), wrap it in a SQL insert statement, etc. etc. I used it a ridiculous amount and at times it made me look far more efficient than I really am.
I'm on the business side now but even today I found myself cleaning some data with multiple cursors, sorting alphabetically, and then using a 'count duplicates' command I found on GitHub to remove duplicates and prefix each line with the number of times it was duplicated. I could have done it in excel, but it took me literally 20 seconds to do it in Sublime.
149 comments
[ 6.1 ms ] story [ 257 ms ] threadI’d like to kick back on my couch and code for an hour using my iPad and Apple Pencil.
I’m anxiously awaiting for someone to image a better mobile experience rather than attaching a hardware keyboard.
Using something like "ci(" to blank the parentheses under my cursor and immediately start typing a replacement saves me, like... a couple of seconds. But it gives me a little dopamine hit that I think helps with job satisfaction.
Yeah, same. I recently realized that I use vim‘s normal mode features even in situations where I’d certainly be faster just typing things out manually, just because it feels good to “work smart”. Even if it’s not really.
Another downside: using (and watching people use) editors without vim features becomes painful.
I can't seem to see it without enabling javascript.
> I have never been a power editor user; typing just never felt like a bottleneck worth fighting over (unlike exploration). It is interesting watching my kids get excited as they discover various Sublime Text features that I never use.
and
"I am talking about generic text editing features; I definitely find language/IDE features like intellisense very valuable, and, as someone else mentioned, a good integrated debugger is among the most important things. "
https://nitter.net/id_aa_carmack/status/1302651878065475584
There are browser extensions to automate this too but I haven't tried any yet.
It's easy to get lost in fancy editing techniques that get you a win of minutes per day (as Carmack mentions), while learning to come up with a better design will save you weeks in overall development time. Learning more editor shortcuts is much easier and more flashy, of course.
Past a certain point the returns are rapidly diminishing and you burn a lot of time and effort on very marginal gains that would be much better invested on bigger picture, higher impact stuff - namely, the actual thing you're building. I wrote a blog post on this that you may enjoy [0]. I like your F1 analogy, I used tennis :-)
[0] https://davnicwil.com/just-build-the-product/
I knows a famous movie composer who plays the piano with his two index fingers.
(Of course, most are at least competent at it, due to plenty of practice.)
By a couple orders of magnitude, what’s going on in your head is a lot more important than what your fingers are doing.
I would say speed of typing and amount of code produced have no relationship to the quality of the programmer. Of cause there might be exceptions if people was trying to type with one finger at a time and other wierd things but above basic typing skills I cant see how it matters.
For me, Termdebug is the killer feature. There's something about being able to debug things faster than the other IDE-using folks, who are usually just waiting for the spin-up of their IDE into debug mode to stop by the time I've already stepped through the code in focus ..
I think a lot of people would be in the vim camp if they could just master the 5 basic operations they'd need to use vim. Its pretty interesting to discover the whole world of stuff in help.txt that I just never, ever touch, for whatever reason ..
https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
If that is accurate (it looks like it is), why is termdebug faster than keeping open a second window and using gdb there?
But, even though I bring vim keybindings to all my local editors, my day to day is still a mix of vim + mouse navigation (and cmd+t obviously). I have never felt hindered by not being all vim.
I do touch type though, and have known programmers who hunt and peck with their index fingers. Not being able to type nowadays always seemed odd to me since, I just assumed people would learn to type better by being at the computer all day.
If you have broad shoulders and long arms, finding a good posture is even more difficult.
I've noticed that with doctors. Maybe it's just where I live, but most doctors I've met hunt and peck. It's painful to watch them struggling to type their prescriptions. Considering how valuable their time is, it's a shame they don't spend time learning this skill.
Honestly if someone showed up with a keyboard driven GUI that completely lacked mouse input and had a modal paradigm I might actually use it over vim.
> Yes, it can be very impressive watching people using the power tools to maximum advantage, and sometimes is can be a dramatic win, but I usually think that it adds up to... a few minutes saved a day?
I think measuring the gains of text editing features in terms of time is a distraction. Expressive editing features take something tedious and make it effortless. It makes it easy to do something that I'd normally put off.
But the reason text editing features end up not being that important is that if the task is mission critical, you'll end up just soldiering through, even if it's tedious. Therefore it's an incremental benefit not a revolutionary one.
I like text editing features because I personally like being organized, not because I feel like it makes me a more effective programmer. It lets me indulge myself in keeping code organized without that becoming a time sink.
However, for those 1-2 hour focused coding sessions, it is easer for me to enter and stay in flow when I feel a better connection to my tools. Since I do perhaps a dozen of those a week, I am able to accomplish more and do it more enjoyably, even if I only spend 20% of my work time in one of those sessions.
I am not sure exactly how much the productivity increase is because I haven't tested it rigorously (honestly not sure how to even measure that), but I'd guess it's still only 5% at most. The benefits to my happiness and fulfillment when coding are definitely noticeable though, and I think it is because I am able to spend more time in flow.
Edit: and for what it's worth, there are things that arguably have much greater impact on my ability to stay in flow than just the text editor: how good the debugger/REPL is, my familiarity with the language and libraries related to what I'm doing, etc.
* would argue that a lot of people who write things like 'it only saves a few minutes a day' have never actually tracked how much time it actually saves
* one good thing worth doing is to get a tool that tracks how much time you spend on different applications and websites during your work day
it will TRANSFORM your understanding of how you use your time
Every single IDE and text editor for programmers can do this stuff, and they are often the only features that 90% of users learn.
Having quick access to options is paramount - like vscode F1.
Besides, huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs, even if the feature exists. Its the IDE mindset (personal experience).
There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.
> huge majority of IDE users do not use keyboard shortcuts but browser trough its GUIs
Does it count if you "browse the GUI" without ever touching the mouse?
I use the "search everywhere" [1] dialog in JetBrains by pressing double-shift all the time. When I used emacs, I would M-x tab-complete commands all the time. Same thing.
Which requires more effort: pressing 4-ish keys to spell out an editor command you use only a few times a day or trying to memorize every arcane key combination?
Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.
I say it all the time, but I think a lot of power vi/emacs users have not touched a modern IDE in a long time. Everything is keyboard accessible nowadays, and I would argue vastly more discoverable compared to vi/emacs.
I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.
[0] https://github.com/acejump/AceJump
[1] https://www.jetbrains.com/help/idea/searching-everywhere.htm...
Yeah, modern IDEs got some stuff from modern editors for sure. One of the primary pain points for me is that installation/setup of IDE is much more lengthy, they are pricey too - I can setup vim/code in minutes on empty machine. Just downloading/installing VS takes a bunch of time. This however has nothing to do with efficiency but counts overall.
> There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more powerful than stock vi navigation commands.
The page you posted lists InteliJ Platform. Vim doesn't have such plugin OTB FYI.
> Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I think so.
If tabbing is done via mouse, yes.
> Does it count if you "browse the GUI" without ever touching the mouse?
Ofc not, I prefer to have a GUI, I just don't think analog controller like mouse is good way to interact with it.
> I also think that there is a strange magical thinking-esque hang-up against any UI that can't be drawn in a terminal.
That might have been a real thing when people did things on servers directly etc. Today there is almost 0 need to do so.
There's nothing magical about it.
I prefer text based interfaces whenever available as they are generally more responsive, light on resources, use less network bandwidth, and are inherently compatible with SSH. They also tend to be very minimal, having far fewer extraneous features (ie fiddly distractions) due to the inherent design constraints.
If one isn't available though then I'm happy to use a modern GUI (my web browser is an example). In fact, GUIs consistently seem to be more newbie friendly so if it's a one off I might actually avoid a text based interface just to save time.
Watch as my eyes roll out of my head, onto the floor, and then out the door.
Why is it that you believe the only reason why a vi/emacs user could believe those environments are faster to edit in is because they don't use IDE's?
The worst part is that most vi/emacs users actually DO have experience in both environments, whereas most of the people who want to claim vi/emacs isn't any faster don't. Yet they want to present themselves as an authority.
And I'm one of the people who refuse to use vim emulators in IDE's because they're never quite right (and never integrate well with the IDE).
Anecdotal, personal experience, including seeing constant outright incorrect claims about graphical IDEs in threads like these.
The claims usually take the form of: "I use vi/emacs because I can do xyz using only the keyboard" - where xyz is something that most IDEs maybe couldn't do 15+ years ago, but which they all can do today.
It's not generally that people are saying it's impossible to do in an IDE, just that it's slower to do, and generally more awkward.
Just the other day on reddit I was having this "discussion" with someone, in which they claimed that because they have "find in files" in their IDE it's equivalent to vim `grep -iRl whatever`.
In reality I'm going to do what you're trying to do in a fraction of the time. IDE's have their advantages, but speed is not one of them.
I feel this way about version control systems. More trouble than they are worth to me, even when working in the same tree with many others. If I make a branch, it's only because that's the only way to submit a PR. Merge conflict? I'll look at my diff and apply it manually to the other side. Merkle trees are great, but the only useful history to me is a straight line!
I am a long-time Emacs user. Occasionally, editing/macros/etc can save a LOT of time, and makes it much easier to make some changes which I might not decide to do.
What I find more important however is the effective window/buffer management. Being able to manage my screen real-estate is killer; being able to do everything within one "world" is really valuable. One of the things I find most valuable is that I run my shell within Emacs. This lets me keep my flow going instead of switching context and perhaps getting distracted. I can watch the output of tests etc in one corner of my screen and edit files etc in the other ones. And because its quick to switch buffers, I can more easily reference various files for what I am doing.
Basically, the literal time it takes to type is not the big benefit, but that it allows me to reduce my cognitive overhead of doing everyday, boring things like resizing windows, looking up symbols/finding definitions etc. This makes it easier to focus on my task at hand and not get distracted by all of the mundane tasks I would need to do otherwise.
Yes! I cannot imagine how my life looked before `C-x b` (switch buffers in helm).
However, I still have an actual terminal emulator open the entire time for serious stuff. Eshell is not compatible with a lot of programs, term/ansiterm are ok but not quite as good as a dedicated terminal.
I get around having to context switch by using virtual desktops (KDE). I have Shift-F1 bound to the desktop with only emacs, and Shift-F3 to my terminal. Works beautifully.
Rather than try to use a terminal in emacs I've found it more useful to use an solution designed for emacs, i.e git vs magit.
For full screen apps that absolutely have no Emacs equivalent (quite rare), I have a term buffer that I occasionally use.
You should check out a list of eshell features, its much more powerful than even zsh.
Also I use company-mode for command and file completion, which is a lot nicer than zsh 's completion method, for example. Once you get used eshell, it's hard to go back.
I think you should be able to use eshell+Emacs for almost everything, and for me at least, I find the experience quite nice.
I do keep a terminal open for a variety of reasons (and some curses apps don’t work perfectly in emacs) but I probably only use it every other work day.
i don't know about emacs, but out of the box switching buffers is easier/faster in tmux than in vim (maybe i need to learn more vim).
That’s fine. I would probably argue that it’s easier to get there with emacs, and having one language is a lot nicer than having to learn vimscript, whatever tmux uses, etc, though neovim makes that a totally different discussion because iiuc you can script with many different languages, and emacs lisp, while pretty decent, isn’t great.
Probably the biggest issue facing these environments at this point is that need stronger types to scale better. Doom emacs helps with this because it locks packages down, but for example spacemacs was always broken for me. So eventually I switched.
Anyway if you want to try it I’d recommend doom emacs. It uses vim style bindings so your muscle memory won’t atrophy
But I think there are people whose job involves cranking out code all the time and I can see why it matters to them.
Well not until HN introduced me to dotfiles...
I used to have a pretty nice emacs setup but this year I have been coding python in gedit (notepad.exe of Linux) and I've done just fine.
That seems like the most any modern developer/*nix user should need to concern themselves with vim and wholly for the reason I mention above: it's the most likely text editor to be there on unix-like systems.
So while it can certainly be impressive to watch someone who has mastered their editor, I always secretly kind of doubt that it's really much of a productivity win for this reason.
I think there are huge wins for getting proficient with your editor (refactoring commands, debugger, etc. as John Carmack mentions), but sharply diminishing returns beyond that.
> So while it can certainly be impressive to watch someone who has mastered their editor
I'd say anyone who spends a significant amount of time tweaking their editor while they should be working, outside of (infrequent) setup periods, has not mastered their editor (or is just slacking off). The entire point of setting this up is to make you more efficient.
Same thing goes with having a pipeline of transforming data from one format to another. Do you use a simple ad-hoc method where you just use features in the tools (Text filtering + Import to Excel + Manually creating graphs), or do you write scripts to automate part or all of the process?
When should you stop doing things manually and automate them instead?
When your best estimate is that spending the time to automate it will be a net benefit in the long run. (https://xkcd.com/1205/) This is hardly unique to configuring an editor or IDE though.
If someone is repeatedly and consistently spending "half their day" configuring their editor then either they don't really know how to use it, or they're slacking off, or they consistently make bad time estimates (https://xkcd.com/1319/), or you don't actually understand what it is they're doing and why.
And even if I only saved a few minutes a day, over several years that is a lot of time saved, without much investment. It's really easy to get started with vim, get comfortable with the basics in an hour or two, and then just get better by using it every day. Then you can slowly introduce features that save you time. Just setting up fzf and ag has probably saved me several minutes a day vs. using vscode search.
Is there an IDE that does not have this feature?
It's a point that a lot of IDE users miss. I have grep and awk at my fingertips, you don't.
I think the reason programmers love to tinker with their vim or emacs configs is because it's simply satisfying. Just like a blacksmith has their very own set of valued tools, there's something extremely rewarding about configuring your setup just the way you want it. You work your entire life with it, so you might just as well make it your own, I think that's what people get out of it, just a subjective sense of making things fit right.
It's like my barber who has some cool vintage scissors he got from someone. Could he cut my hair with some high grade scissors he bought on the internet? Sure, but he likes his ones better. At the end of the day programming is more like a craft than a science and it shows when it comes to topics like this.
It's not about typing speed at all (for me). It's about having a clean and orderly working environment where the number of frustrations have been minimized.
Therefore I'm tempted to look at this problem not from a technical but rather from a social perspective: I consider this preoccupation with editors as a kind of fixation and way of exercising power in a straightforward way as a part of an increasingly complex and unfriendly environment. We can't customize the stupid Scrum processes guiding our lives, can't customize the management which often is rather clueless about what we're doing, can't avoid that most software projects are ultimately pointless even if they claim they're changing the world and empowering users. But we can certainly customize our editors.
And then there's the social pressure from the typical hacker circles which would happily dictate what programming languages, tools and paradigms are good and which are bad. Of course this scaffolding all comes crashing down when one looks at the results and there's no discernible difference between the quality or success of projects where various editors or processes or languages are used. So the focus moves to personal benefits, personal preferences and programming as craft and so on.
But it's all just a game programmers play, isn't it?
That's not even half of it. TUI programs are designed to be keyboard driven from the start, not as an afterthought. All the IDEs I'm aware of are hopelessly outclassed here. There's also things like registers, column editing, and the buffer abstraction which make common tasks less cumbersome. The list continues.
It's not that one tool can be used for a task that the other can't; rather it's just better at it from my perspective (given my particular workflow and toolchain). For me, there's a significant ergonomic difference which makes for a more pleasant process overall.
Is keeping a clean and orderly workspace "just a game"? What about using the best (from your perspective) tool for the job? I imagine different people will care about these things to different degrees.
As you point out, perhaps for some there's primarily another motive (exercise control, irritate a coworker, maintain an appearance, ...). That's not mutually exclusive though and it's hardly unique to programming.
I think there’s more to it than that. Yes, it can be very satisfying to tinker with one’s tools rather than getting work done. But that doesn’t explain someone like me who took the time to learn vi (not vim) rather than using a basic text editor like nano or Notepad or TextEdit.
So why would I take the time to learn vi? I don’t tinker with it (beyond adjusting a few basic settings like autoindent, line numbers, incremental search, etc). It certainly took me a long time to get very proficient with vi. It’s also the case that any editing task I can do with vi can be done in any other text editor (they’re all “text equivalent”).
The answer is that vi, more than any other editing method, removes friction from the editing process. Having used it for a long time, I’ve built up muscle memory that allows me to rapidly jump around files and make precise edits. It also lets me easily automate repetitive editing tasks with its ex commands, macros, and of course the humble ‘.’ command. In the case of more elaborate tasks such as paragraph formatting, table formatting, or inserting line numbers into the text, vi lets me easily pipe motions, ranges, or buffers through shell commands.
So why doesn’t everyone use vi? Well that’s specific to personal taste. Some people don’t get as frustrated by friction in the editing process as I do. Maybe John Carmack doesn’t mind reaching over to grab the mouse in order to move the editing cursor somewhere else, or to select text for copy and paste. I don’t know what his editing environment and workflow look like. Perhaps he uses some other editor like vi but with the default configuration.
I guess there’s one more piece to clear up and that’s the question of whether or not I qualify as a “power editor user”. I think I do. I don’t tinker with my editor to the incredible extent that some others do, for sure. I used to tinker and found it a deep rabbit hole of distraction which inevitably led me to a slow and complicated environment (highly customized vim) that really didn’t do anything fundamentally faster/better than I could already do in plain vi. Having said that, I think my experience with vi (including having purchased and read O’Reilly’s book on the topic [1]) has helped me to master its commands far more thoroughly than a typical vim user. So I think that qualifies me as a power editor user. Others may disagree.
[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...
You get immediate feedback on every change. It feels like you’re doing something.
For much of my self-taught coding ability, I’ve been tinkering with configuration files that don’t seem to move the needle.
The time I spent on my editor was the distraction.
I spent a ton (no, really a metric ton) of time tweaking my vim and emacs configs, and have thousands of lines of code in each, but I haven't touched either in years, and I'm pretty happy with that.
Yes, tweaking editor configs is fun, but I have other interests too, and those other interests have taken priority for a long time now.
Incidentally, I consider all that time tweaking my configs very well spent -- not because it was fun, but because my editors are enormously useful to me now, and I wouldn't dream of ever going back to more primitive editor.
I've used multiple cursors for many purposes, initially as a dev it worked very well as a poor man's ETL - take a spreadsheet and perform a bunch of transformations (reverse first name and last name, trim these fields, add leading zeros to this field, concatenate these fields, delete this field, use some sublime plugins to generate incrementing IDs, etc.), wrap it in a SQL insert statement, etc. etc. I used it a ridiculous amount and at times it made me look far more efficient than I really am.
I'm on the business side now but even today I found myself cleaning some data with multiple cursors, sorting alphabetically, and then using a 'count duplicates' command I found on GitHub to remove duplicates and prefix each line with the number of times it was duplicated. I could have done it in excel, but it took me literally 20 seconds to do it in Sublime.