[HN Gopher] Vim is touch-typing on steroids
___________________________________________________________________
Vim is touch-typing on steroids
Author : rl1987
Score : 119 points
Date : 2023-01-12 05:14 UTC (1 days ago)
(HTM) web link (www.trickster.dev)
(TXT) w3m dump (www.trickster.dev)
| zabzonk wrote:
| just me - i've been using all the vi-derived editors as my
| favourites since the mid to late 80s. never learned to touch
| type.
| memorable wrote:
| Kind of the same here. I never actually learned to touch type
| correctly on QWERTY, though I do it when learning other
| keyboard layouts.
| stevebmark wrote:
| Touch typing is one way to put it. I would say Vim is an
| imperative editor. You need to tell the computer how to edit text
| by glueing together chains of small painful commands. IDEs are
| declarative editors, you say you want to refactor a variable, and
| the IDE handles it.
|
| Vim is a text editor, not a code editor, and I keep forgetting
| how weird it is. "Ctrl-X Ctrl-D completes a C preprocessor macro
| by default" - there is no reason this should be in the core of
| any editor.
|
| And finally, whatever you think of Vim, it's not worth using
| unless you've read Practical Vim. Without the knowledge of that
| book, you're too limited to approach efficient (imperative)
| editing.
| urthor wrote:
| Practical Vim is worthwhile.
|
| Unfortunately, I had to put it down to read the 695,378 word
| Vim manual.
|
| Or at least, the 33,807 word core essentials.
|
| Approachability is... not Vim.
|
| Especially when both the manual and Practical Vim to absorb
| "how to use it" are a such a necessity.
| alwillis wrote:
| I didn't read either Practical Vim or the docs before
| becoming pretty proficient with Vim.
|
| Some good blog posts and some videos did it for me. I had
| enough knowledge to make diving into the docs more
| meaningful.
|
| Besides once you understand the language of Vim, it's not
| hard to make strives.
| AlchemistCamp wrote:
| It's not an either or.
|
| In fact, any IDE (or any coding environment) lacking VIM
| bindings is broken.
|
| As long as my computer is beefy enough, I'm perfectly happy
| using Jetbrains or VS Code or whatever IDE, but I always use
| VIM bindings and it's been a key piece of my recovery from
| severe RSI. It's been a nice productivity boost, too.
| guipsp wrote:
| >In fact, any IDE (or any coding environment) lacking VIM
| bindings is broken.
|
| Not a fact. You just prefer vim bindings, which is fine.
| Other people prefer other schemes, which is also fine.
| AlchemistCamp wrote:
| VIM bindings are a very, very common preference and were
| one of the first suggestions I got when dealing with
| repetitive stress injuries from extensive computer use and
| were key for my recovery. It was also key several others I
| know who have been through similar, albeit less extreme
| injuries.
|
| I'm all for IDEs supporting many different bindings, but
| lacking VIM bindings is an accessibility issue and shuts
| out a significant % of the possible users.
| stevebmark wrote:
| You exhibit the "Vim mode paradox." If you're comfortable
| using the limited "Vim mode" in other editors, you don't know
| Vim well enough to justify using it.
| pxc wrote:
| You've forgotten that nobody has to justify using the tools
| they like :)
|
| But also, some Vi emulation modes are much, much more
| complete than others.
| phowat wrote:
| No vim mode is perfect, but they do make other editors
| bearable. I think vs code's is the closest one I tried.
| Though I never really used it as my daily driver.
| eloisius wrote:
| To me vim mode is just enough to keep me from
| ragequitting something like Xcode when using vim is
| practically not an option, but "vim" mode would never be
| enough to make me use another editor by choice. Vim isn't
| just hjkl.
| bnralt wrote:
| I tried Vim mode in XCode. When I move by paragraph,
| XCode crashes when it gets to the bottom of the screen.
|
| I understand that XCode Vim mode is lacking a lot of the
| functionality of Vim, coming nowhere close to even the
| free XVim plugin. But you think they could at least make
| sure the few features they do include aren't completely
| broken.
| tasuki wrote:
| I used vim as my primary code editor for over 15 years. Now
| I use IntelliJ vim mode and am happy with it.
|
| You're saying I don't know vim well enough. What important
| vim features (which I'd use if I knew vim) is IntelliJ
| missing?
| nayaketo wrote:
| Lolwut? I use Vim plugin for Visual Studio every day and
| although pretty limited compared to full fledged Vim, it's
| still extremely powerful. Besides hjkl movement, I still
| get splits, registers, macros, search/replace, formatting
| and the aforementioned features are easily 95% of Vim
| features I used to use Vim for. So the limited experience
| is still pretty great and I don't know how to use VS
| without this plugin anymore.
| rcoveson wrote:
| > Without the knowledge of [Practical Vim], you're too limited
| to approach efficient (imperative) editing.
|
| Are you the publisher or something? What a weird thing to say.
| I haven't read it, so I guess I'll go back to using nano--after
| 15 years of vim--and just suffer?
| unsignedchar wrote:
| Yeah that was weird. How were we using vim for 20 years
| before that book ?
| stevebmark wrote:
| I have no affiliation with the book nor author. I've also
| been using Vim for about 15 years.
| ARandomerDude wrote:
| > And finally, whatever you think of Vim, it's not worth using
| unless you've read Practical Vim.
|
| Uh, what? I find it absolutely painful to watch my coworkers
| click around in their IDEs. It takes them forever to get things
| done.
|
| Of the handful of hard core Vim users in the office, I'm the
| least sophisticated. But I'm WAY faster than all the non-Vim
| users.
| calvinmorrison wrote:
| Every few years I trot out some vim command new to me and it
| falls to the wayside. I don't even use buffers right, I use
| tabs. Which are apparently a bastardized version but I
| digress.
|
| F f g G jkl; ESC i r R yy p and control A and control E
| probably cover 90% of my cases.
|
| However. I use a nub on my ThinkPad so I have sort of instant
| mouse access for location things, I mostly use jumping for
| inside a line
| deathanatos wrote:
| Try :normal (:norm for short.) It can edit a set of lines
| given a certain set of vim commands. Sometimes simpler to
| reason with than regexes.
|
| E.g., if you want to turn, * a * b
| * c
|
| into, "a", "b", "c",
|
| V, highlight the lines, :norm 2xi"^[A", -- 2x to remove the
| star+space, i" to insert the quote -- now we need to get
| out of insert mode, so that's tricky: Type ^V ESC there for
| verbatim ESC (I've rendered that in the command as vim
| will, ^[, but it will be colored to denote that it's a real
| ESC character) -- then A", (append a quote and a comma).
|
| You could do it with a regex, but I just find it far more
| natural to list the commands: my brain is already imaging
| it that way: remove the bullet, add the quotes and the
| comma.
|
| Good for-loop for "do this to each line". Sometimes takes a
| bit of back & forth to construct the command, or sometimes
| it's just easier to do multiple :norm's. One of the best
| additions to my repertoire in years.
| doix wrote:
| Buffers and tabs serve different purposes. I think a lot of
| people dismiss tabs because they don't understand their
| purpose. It's not just about switching to different buffers
| quickly.
|
| Tabs are an organized collection of windows, and you can
| quickly switch between them. I might organize my windows so
| half the screen is one buffer and on the other half, is
| split 3 times horizontally. Then I edit some code and
| realize I need to edit some other part of the codebase. I
| make a new tab instead of changing buffer, so I can go back
| to the view I setup already without having to recreate it.
|
| Tabs are the true power of vim, I don't have that
| functionality in any other editor (apart from Emacs?) and I
| miss it constantly. Buffers aren't really a novel concept,
| they work the same in VS code and JetBrains IDEs.
| sodapopcan wrote:
| Ya, "tabs" are a misnomer coming from almost any other
| editor which is unfortunate. Vim doesn't have what most
| people think of as "tabs" (I guess you could think of
| them as "dynamic" tabs but I digress).
|
| Vim has been my only code editor for the past 10+ years
| and I wish I used tabs a little better (ie, the way you
| describe). As it stands I have some plugins that open in
| a tab so they are easy to close (like gv.vim) and
| otherwise use my tabline as a secondary status line (it
| tells me my working directory and if I'm tracking a
| session or not).
| Aperocky wrote:
| airline and bufferline plugins are great - it helps
| unify/bridge buffer and tabs
| sodapopcan wrote:
| I never liked airline as I felt it was too busy and I
| like customizing my own statusline, though you've piqued
| my interest with how they deal with tabs. I actually like
| vim's tabs just as they are--I mostly need better mapping
| for manipulating them. I'm otherwise a dual-split-with-a-
| mark-or-two person.
| pxc wrote:
| > Tabs are the true power of vim, I don't have that
| functionality in any other editor (apart from Emacs?)
|
| Yeah, Emacs also lets you do that! You can achieve
| similar workflows via tmux or a tiling window manager as
| well. It's my favorite way to work! For whatever reason
| I've never gone down the tiling WM rabbit hole, but I use
| this kind of thing in Emacs and tmux all the time.
| doix wrote:
| So I do use a tiling window manager, but the problem is
| that to take advantage of it, I'd need the editor to put
| each buffer in its own (real xorg) window. I couldn't get
| something working with either vscode or IntelliJ.
|
| One editor that does support it, is kakoune. I forgot
| about it when writing my previous comment. Each instance
| can connect to a server, so they can all share
| registers/buffers/etc. Then you can use tmux or your
| window manager to create the layout you want.
|
| It's very clever, I actually think it's superior to vim,
| as you aren't limited to organizing your views inside a
| single vim "main" window. You could do stuff like kak |
| browser | kak, and both kak instances share everything.
|
| Unfortunately I can't get used to the kak commands so
| I'll probably never change. Perhaps neovim will one day
| implement something similar.
| [deleted]
| voidhorse wrote:
| It's not so much the absence of vim as it is their apparent
| ignorance of the magic of hotkeys. Download a vim plugin for
| your IDE and you get modal editing (usually w/ vimrc binding
| support) too. imo that's the absolute best way to go. You get
| modal editing speed, modern UI, better autocomplete over a
| wider bank of languages, two key press project wide
| refactors, go to definition without needing ctags, a terminal
| in the ide so you can still run commands easily (typically
| better than vims term window does), git integration...the
| list goes on and on. And sure, you can download a huge set of
| vim plugins to get something close, but the ux will never
| feel as unified as it does in an ide and it takes extra work
| to maintain your rc+.vim...
| Aperocky wrote:
| Vim binding is great and I find it solves at least 90% of
| my usage.
|
| It's the 5% of vim that's unavailable (i.e. norm, macros)
| and 5% of needing to still click the IDE UI occasionally
| that reminds me that it still isn't vim.
|
| But then again, for some language families there just isn't
| a choice.
| doix wrote:
| > but the ux will never feel as unified as it does in an
| ide
|
| I argue the opposite. Because vim is such a constrained
| environment, the UX is extremely unified.
|
| An IDE with vim mode is the opposite. Vim mode usually only
| works in the text buffers and nowhere else (at least not
| properly). You need to memorize a combination of vim
| hotkeys and regular ide hotkeys OR spend a long time
| messing around with your IDE hotkeys (probably comparable
| to vim config).
|
| In vim, since everything is a buffer and a window, you can
| use your regular navigation hotkeys to move between them. I
| just think "I want to shift my focus to the window on the
| left" and it doesn't matter if the window on the left is a
| text file or some plugin.
|
| In something like IntelliJ, you can't "just go left". You
| need to know what the hotkey is for the panel on the left.
| The "non-modern" UI, which constrains vim actually makes a
| significantly more unified experience.
|
| > terminal in the ide so you can still run commands easily
| (typically better than vims term window does)
|
| This is a perfect example. How do you switch back and forth
| between your terminal and text file in an IDE? How do you
| copy paste between your terminal and text file? Can you use
| vim movement in your terminal that you opened in your IDE?
| Or your registers? In vim, that all works perfectly just
| like you'd expect without learning anything new, it just
| works like regular vim.
|
| That being said, I still use IntelliJ if I'm writing
| Kotlin. The semantic analysis they can do is absolutely top
| notch, can't get something comparable in vim and the
| productivity gains out weigh my annoyance with the
| inconsistent UX. Something like python though? I'll
| probably stick with vim, jedi is good enough.
| jrockway wrote:
| I very much agree with this. It is very tedious to edit code
| without a "text editor". By the way, Vim and Emacs have all
| the fancy refactoring / formatting / navigation things that
| VS Code does; using the exact same implementation. You get a
| no-compromises best of both worlds, at the cost of a lot of
| front-loaded learning. (That is to say, I get why Intro to
| Python books don't suggest learning vim. One problem at a
| time. But someday, it will really help you with the mechanics
| of slinging code to have a featureful text editor around.)
| galangalalgol wrote:
| Python without vscode and pylance is rough. And even then
| you need to keep up with the typehinting. Vim and python
| leaves me with all sorts of horrific runtime errors to
| debug.
| Aperocky wrote:
| Write unit tests.
|
| I write unit tests for my personal projects - it might
| sounds ridiculous but it is the reason why I can grow
| these projects beyond the initial 12 hours of interest.
| Since personal project tend to be on the smaller side I
| usually uses typescript or python but I've never found it
| an issue where pure vim usage becomes an issue at scale.
|
| It also strongly enforces separation of concern in terms
| of file organization. I found using vim for development
| to be a positive feedback loop.
| galangalalgol wrote:
| Insisnwrite unit tests, but they often passed for reasons
| other than the intended ones because of the dynamic
| typing. I kept adding tests every time I caught something
| runtime, but I was at an order of magnitude more tests
| than I would need with a strong and static types
| language. Pylance kept me from making thos mistakes in
| the first place.
| ilikehurdles wrote:
| Vim has all the same language servers that vscode has,
| with all the same capabilities.
|
| e: never mind, I see Microsoft closed sourced pylance and
| restricted it to their products. Typical. Of course there
| is still pyright along with a python language server, but
| I guess technically not pylance any more.
| seanw444 wrote:
| I use Pyright with Doom Emacs at work, and I have no need
| for anything more. And I work on a relatively large
| Python codebase.
| cdogl wrote:
| What a peculiar statement. I've been using vim as my go-to
| editor for most of my 10-year career as a software developer. I
| am very productive. I haven't read said book.
| bradrn wrote:
| > I would say Vim is an imperative editor.
|
| It's interesting you say this, since I've always thought of it
| in precisely the opposite way! A traditional editor is
| thoroughly imperative: all editing operations are built up by
| sequencing basic commands, almost exclusively 'insert/delete a
| character', 'move to this line/column', and 'select from
| line/column position X to position Y'. By contrast, Vim gives
| me an entire declarative language to work with text: if I want
| to 'delete a word', or 'change the next 10 lines', or 'move to
| the previous occurrence of the identifier under the cursor', I
| can just _do_ that, without having to mentally break it up into
| sequences of smaller editing operations.
|
| I suppose this all goes to reinforce a point I've made several
| times before, which is that 'declarativity' is more of a
| continuum rather than a state. Calling something 'declarative'
| without context isn't very helpful, but it's entirely valid to
| say that most text editors are less declarative than Vim, and
| Vim is in turn less declarative than the refactoring operations
| in a full-featured IDE.
| pxc wrote:
| > I suppose this all goes to reinforce a point I've made
| several times before, which is that 'declarativity' is more
| of a continuum rather than a state.
|
| To me, it seems clear that editing an existing body of code
| is always imperative-- you're literally manipulating the
| state of the text iteratively, no matter what you do! Code
| _generation_ can be declarative. But you 're still going to
| imperatively edit your declarations somewhere, in that case.
| :-P
| GavinMcG wrote:
| My dream, as someone who writes text rather than code, is to
| move that next step along the continuum. I want a motion for
| "change sentence to future perfect tense."
| packetlost wrote:
| That actually sounds somewhat reasonably attainable with
| recent advancements in natural language AI models.
| voidhorse wrote:
| Pretty much. I tried using vim as my sole driver for a long
| time then finally saw the light that modern IDE + Vim mode
| plugin is the one true holy path.
|
| Vim is wonderful but a massive waste of time and the quality of
| plugins is just lower jn general (obv. there are several
| exceptions, zig language support, for instance is much better
| than a lot of other vim language support plugins out of the
| box). The modal editing can't be beat, but frankly it's just
| way more painful to do sophisticated things in Vim than it is
| in a modern IDE. At best you need to produce a write once
| vimscript and hook it up to a command. Contrarily the
| ecosystems of modern IDEs are so large there's actually a
| greater chance someone already solved you problem and provides
| it with one click/hotkey. For me, vim is nothing but a constant
| distraction generator. Instead of being able to focus on what I
| actually intended to get done I'm ever tempted to go off
| writing some vimscript to solve some edge case I just
| encountered while editing or to automate something--much better
| to just make it a nonoption, at least for me. I'm sure there
| are vim gods out there that have an entirely different
| experience.
| Aperocky wrote:
| I am no vim god but I have a different experience.
|
| I've installed quite a few plugins (e.g. nerdtree, airline
| etc) but they are mostly cosmetic and I myself don't do much
| vimscript other than some basic .vimrc. But I do have most of
| the content of any vim cheatsheet burned into muscle memory
| and can come up with combination of them on the fly. I also
| use :norm extensively when I need to quickly batch edit
| anything.
|
| I never really did encounter scenarios where the logic are so
| complex that I'd rather write vimscript to solve it - at
| worst, I'd do a macro, but combination of modal keys are
| usually enough. I think I find a sweet spot between using vim
| to its maximum utility and less about using vim for the sake
| of vim.
|
| I have a quick install script for everything I depend on and
| one thing I found _extremely_ valuable is the ability to
| pull, install and have the same editor customized and
| familiar in any computer, virtual or real, it even works on
| Windows (WSL).
| idontwantthis wrote:
| I haven't read it and I use Vim every day. Like any skill, just
| learn as you go. A couple of times a week I google for how to
| do something I figure is possible, then I save the link in a
| bookmarks folder.
|
| I might read it at this point and learn a lot, but I'm still
| happy and productive with what I do know.
| narrator wrote:
| You can get vim keybindings for Intellij so you get all the IDE
| stuff too.
| xwdv wrote:
| Vim is neither a text editor nor a code editor.
|
| Vim is a _language_. To speak Vim is to speak in a way with
| your hands that turns words into action and moves text at the
| speed of thought.
|
| I have long mastered Vim after over a decade of experience. I
| can barely tell you what keys I'm pressing, but when I imagine
| some text in my head and how I'd want to change it, I feel the
| force at the ends of my fingers that guides my hands until the
| modification is done.
|
| Much like how you can speak to express an idea without having
| to think about the way your mouth moves, I can easily edit
| blocks of code without really knowing how my hands will move, I
| simply trust they will do what I need and it happens. Vim has
| become the interface by which my mind can directly immerse
| itself into the conversation of code on a screen. Most will
| never understand the feeling of this power unless they
| deliberately pursue deep mastery of Vim, but once you've gotten
| a taste of it, it becomes intoxicating.
|
| Vim is well worth investing your time in. I guarantee it is one
| technology that will exist for the rest of your career. The
| year will be 2100, and Vim will still be around and in use by
| the best engineers.
| probablynish wrote:
| What do you think of using vim plugins inside an IDE, such as
| IdeaVIM? How much of the benefits of what you describe do you
| think would remain?
|
| I've been trying to spend more time in vim since last year
| because I can imagine a world with the benefits you describe,
| and I want to put in the long-run investment to get there.
| But at the same time, Vim naturally lacks the feature set of
| an IDE, and setting up a bunch of plug-ins so that they all
| work together is somewhat time consuming and brittle.
|
| I've been wondering if I should stick to Jetbrains/VS Code
| and use Vim as a text manipulation language, and whether I'd
| still attain that editing fluency you describe.
| xwdv wrote:
| Plug-ins are always a personal choice. For me the most
| essential is fuzzy finder with ctrl-P. With this I can
| arrive at any file or line in a massive codebase damn near
| instantly.
|
| I find vim with the right plugins is as capable as any IDE,
| you can at least have the basics like autocomplete and
| various syntax highlighters and linters. Personally I think
| developers who lean heavily on the IDE features of more
| common tools are using it as a crutch for not knowing the
| codebase very well or language features.
|
| Part of the journey to vim mastery is the configuration of
| vim until it fits you like a glove, once you've configured
| it well you rarely need to touch the config files again.
| jatins wrote:
| With LSP support VIM can do most of what you'd do in VSCode in
| terms of language specific refactoring. The plugin ecosystem is
| pretty rich.
|
| Setting it up is still a nightmare, there are pre-made Neovim
| configs that I found helpful to start with (Nvchad, astrovim)
| but even then adding support for a new language is too much
| effort at times (as compared to VSCode where VSCode will
| suggest to download extensions the first time you open, say, a
| .go file and you just have to click)
|
| VSCode with Vim bindings seems like a decent middle ground.
| pseufaux wrote:
| I recently discovered the neovim plugin for VSCode. It's
| fantastic. A step up over the built in key-bindings.
| redtriumph wrote:
| Anyone who wants to get started with LSP in Vim8/9, I've
| found following plugins useful. a.
| https://github.com/yegappan/lsp [this is newer plugin and
| hence there few issues] b.
| https://github.com/prabirshrestha/vim-lsp
| jzelinskie wrote:
| I've struggled with this since basically nvim started
| supporting LSP and few months back switched to Helix. LSP
| just works the way it should in vim. Sure, I am slowly
| rebuilding muscle memory for the Kakoune-style bindings, but
| it's honestly not much of a leap for having the plugins you'd
| install built into the editor in a cohesive way (e.g. LSP,
| bufferline, git gutters, unimpaired bindings).
|
| I'm honestly shocked at how fantastic Helix is and it makes
| me wonder if all the toil of inheriting vim was worth it for
| the neovim project.
| jatins wrote:
| Gave Helix a try recently and liked it. Much better out of
| box experience.
|
| Something like a readymade nvim config should ideally be
| able to provide similar experience but it's hard to not get
| caught up in the the quest to get it _just right_
|
| Plus Vim keybindings are widely available in popular
| editors/IDEs but I think Helix bindings will take a while
| to get there.
| ts0000 wrote:
| For anyone not understanding why (neo)vim exists, or why some
| developers prefer it to IDEs, I suggest watching "PDE: A
| different take on editing code" [1]. It reframes (neo)vim as a
| "Personalized Development Environment".
|
| I've been using (neo)vim for years, and don't want to use
| anything else. It isn't just about productivity (I would probably
| be as productive in an IDE). It's because its _mine_. It's a
| highly customized environment, catered to my needs.
|
| [1] https://www.youtube.com/watch?v=QMVIJhC9Veg&
| probablynish wrote:
| This is a timely post as I've been trying to use Vim more since
| last year, and recently started a new project with the aim of
| working exclusively in Vim. And I'm torn.
|
| On the one hand I want to significantly increase how fast I can
| manipulate and edit text without reaching for my mouse, a state
| which many commentors here seem to have attained.
|
| On the other, I miss the way that a Jetbrains IDE cohesively
| integrates a lot of features with non-conflicting hotkeys,
| without requiring me to fiddle around with a vimrc - great code
| analysis, Git, database schemas, etc.
|
| I'm tempted by the promise of a plugin like IdeaVIM, which seems
| like it's 90% of the experience - but that'd still sacrifice the
| easy integration with my terminal setup, fzf, being able to
| switch between panes with my keyboard, etc. Does getting 90% of
| the way to being keyboard-free really give you 90% of the
| benefits?
|
| Any tips appreciated :)
| tomrod wrote:
| Still complex for me, even after reading the author's tutorial
| and suggestions.
|
| Between hjkl, w, l, d, dd, esc, :command, and more modes I feel
| like I'll never grok vim.
|
| After how many years do I throw in the towel and just stick with
| VS Code? Been at it since 2008 in some form or another :(
| memorable wrote:
| I have been using Vim since almost day 1 of learning how to
| code and I honestly have never used 90% of Vim's features.
|
| For hjkl I just used arrow keys since they are nicer and I dont
| find much difference between them.
|
| For modes I only learned about Normal, Insert and Visual. No
| more than that.
|
| You could say my Vim editing is extremely ineffective, but it
| is effective enough for me.
| Mc91 wrote:
| I think this is the answer. I started using vi 33 years ago
| and initially learned just what I needed to know. As time
| went on I learned more commands.
|
| If I wanted to erase a word in a sentence, which had seven
| letters, initially I might type x eight times (erase the word
| and a space). Then as I learned more vi I might type 7x. As I
| learned more vi I might type dw.
|
| You can get a lot of navigation and editing done just knowing
| a few commands in vi. If you use it a lot, you can learn more
| commands and have an easier time.
|
| About 7-8 years ago the standard IDE for my programming niche
| changed, and I had to learn a new IDE and what I knew of the
| old IDE I have almost never used since. The vi stuff I
| learned 30 years ago I am still using.
| agileAlligator wrote:
| > For hjkl I just used arrow keys since they are nicer and I
| dont find much difference between them.
|
| The point of hjkl is to keep your fingers in the home row of
| your keyboard. This is generally accepted to be good typing
| practice as it improves speed.
| YeGoblynQueenne wrote:
| >> The point of hjkl is to keep your fingers in the home
| row of your keyboard. This is generally accepted to be good
| typing practice as it improves speed.
|
| You might get some benefit to speed if you keep your hands
| on the home row, or you might not. This is mostly something
| people have been repeating as gospel, but I'm not aware of
| anyone testing it.
|
| Intuitively, using the arrow keys to move the cursor
| without inserting a character should be faster. Assuming
| one is moving around the text while editing, it takes at
| least three keypresses to use hjkl to move the cursor
| without inserting a character: one to switch to command
| mode, one to move the cursor, and one to switch back to
| insert mode. That's because hjkl in insert mode simply
| insert their respective letters. By contrast, using the
| arrow keys to move the cursor without inserting a character
| needs one keypress: to press an arrow key.
|
| Even if you count moving your hand to the arrow keys and
| back as two distinct "operations", and each keypress as a
| single operation, it takes at least three operations to use
| the arrow keys (i.e. as many as using hjkl): one to move a
| hand to the arrow keys, one to press a key, and one to move
| the hand back. Assuming that each operation takes constant
| time, that means that, at best, there is no advantage over
| keeping your hands at the home row and moving the cursor
| with hjkl, than using the arrow keys.
|
| So that idea, that it's faster to keep one's hands in the
| home row, must be a superstition.
|
| Incidentally, I've been using vim continuously since 2011.
| These days at work I use a Spanish QWERTY keyboard, but
| with an English Euro layout. I got the Spanish keyboard by
| mistake and it was simpler to keep using it with the layout
| I know, and benefit from more than a decade of muscle
| memory, than to try and learn the new key positions (and
| combinations). This is another reason why I am skeptical of
| the claim about the home row: muscle memory is faster than
| any spatial optimisation you may think of, or, rather, if
| you've already learned to move your hands one way and can
| do it fast, changing to a new way will slow you down,
| first. And then we're talking about long-term gains of
| maybe a few milliseconds in the long term in this case.
| That sounds pointless.
| agileAlligator wrote:
| > but I'm not aware of anyone testing it.
|
| It definitely worked for me. YMMV
|
| Don't toss it till you try it.
| gsinclair wrote:
| I remap to jkl; to be even more home-row efficient (and
| less RSI-inducing). I wish I did that decades ago.
| JenrHywy wrote:
| I use vim in VS Code - best of both worlds :)
| the_gastropod wrote:
| I think it's common to get overwhelmed with all of vims
| features. For me, focusing on one thing at a time helped. For
| example, spend a day where instead of repeatedly doing:
| A,<esc>j to add commas to the end of lines, learn to do it in
| visual block mode. It'll be annoying and fiddly the first 5
| times. But it quickly becomes muscle memory.
|
| That said, if you've been trying vim seriously for ~15 years,
| maybe it just isn't your thing.
| tomrod wrote:
| > if you've been trying vim seriously for ~15 years
|
| To clarify and to be fair to vim, it's a few days to a little
| over a week of effort every 8 months to two years or so. I'll
| get the bug to ascend in my coding speed after reading an
| article like this one, check to see if I still have .vimrc
| from the last time I tried to configure it for things like
| syntax highlighting, spaces instead of tabs, etc., then give
| it a roll.
| tmtvl wrote:
| I tried from 2013 to 2018, even going so far as to change zsh
| to using vim bindings and then I threw in the towel and
| switched to Emacs. While Elisp isn't the nicest Lisp around
| it's a lot nicer than vimscript, lua, or javascript.
| hyperhopper wrote:
| Check out spacemacs or doom emacs!
|
| Vim has the best interface, but it's built on a pretty awful
| program. Emacs is a pretty awful interface built on a pretty
| great program. Combine the two!
| Aperocky wrote:
| I was like that, then for 2 months I decided I would use vim to
| do everything and use absolutely nothing else to edit text,
| this is when I had joined a new company and ramping up.
|
| About 5 weeks in I ceased trying to make Java work with vim and
| have been using intellij (with vim binding) for Java and
| Kotlin. But kept using vim for everything else, which is
| roughly 50% of work load and stretches several different
| language and config formats.
|
| Have been using vim ever since, the cliff is the hardest part,
| but it was totally worth it.
| jatins wrote:
| I found this extremely useful to learn Vim
| https://github.com/iggredible/Learn-Vim
|
| I first tried the wrong way to learn Vim: memorizing
| keybindings. That's not helpful at all.
|
| Write way to learn Vim: understanding Vim "grammar" as this
| repo teaches.
| makeitdouble wrote:
| Using both when it makes sense should be the best ?
|
| I've seen many coworkers(me included) switch from vim to IDEs,
| but still use it here and there. I think vim alone makes less
| sense in our current environments where we're constantly
| interfacing with many different systems: In my case I need SCM
| status, a command prompt at any time, docker container status
| and commands, quick local to remote file transfer, local and
| remote linting (don't use the same rules) and image previewing.
|
| I could probably make a vim + terminal setup that brings me 99%
| there, but it just doesn't make sense as a time investment TBH.
| And buttons to click are nice, really.
| b0afc375b5 wrote:
| I remember for the first two weeks (maybe a month? it was so
| long ago) learning vim was painful as hell. I had to fight the
| urge to just stick with non-vim mode typing like in default
| vscode.
|
| Despite that I willed myself to continue using vim because of
| the plethora of praise it had, and the promised eternal
| benefits I will be blessed with, so say the evangelists.
|
| After that it was a breath of fresh air to be able to type at
| the speed of thought. I would never dream of going back to non-
| modal editing again.
|
| Now I'm using evil/emacs and couldn't be happier. There's
| another modal editing that's gaining traction called meow, and
| maybe other variants that I want to learn. But for now I'll
| stick with evil/vim-mode.
| charcircuit wrote:
| Vim isn't a CLI based editor. An editor like ed is.
|
| Vim isn't the only editor with shortcuts. Many of the IDEs listed
| come with pretty of shortcuts and you can configure more if you
| want. Those editors also let you use shortcuts without having to
| switch through different modes making you more efficient.
| gsinclair wrote:
| Without wanting to sound condescending, you don't understand
| modal editing. Working in different modes accelerates rather
| than retards efficiency. It's worth knowing about for
| intellectual curiosity, even if you don't care to use it.
| Google "you don't grok vi" for a quick and interesting read.
| charcircuit wrote:
| >Google "you don't grok vi" for a quick and interesting read.
|
| None of this requires a separate mode to do. Modifier keys
| have been shown to be enough to give commands for doing
| operations other than inserting characters.
| throwaway_au_1 wrote:
| >Those editors also let you use shortcuts without having to
| switch through different modes making you more efficient.
|
| The modes are what makes editing in Vim efficient.. you don't
| think Vim users are out here swapping through modes looking for
| the one that lets them paste a line do you?
| charcircuit wrote:
| Yes. Instead of just control + v they have to switch out of
| insert mode and into normal mode, then do a command to paste
| their clipboard, then have to do a command to go back to
| insert mode. It's overcomplicated.
| synergy20 wrote:
| die hard vim user here, can't live without it, keyboard is all I
| need these days, I only use my mouse every 1 minute per hour
| these days, on ubuntu, productivity is higher than IDE for sure.
| and yes vimium for browering.
| chrismarlow9 wrote:
| Vim is an REPL stacked on a real time database that is a buffer.
| makeitdouble wrote:
| If the overall "on steroid" metaphor is on how Vim will improve
| typing performance and give an edge over organically growing your
| keyboard commanding abilities but lead to early health
| problems...I totally agree with the title (also a good piece with
| good advices otherwise).
|
| Vim was my primary editor for a bunch of years, and it's
| definitely fast and helps to utilize keyboard commands to the
| maximum extent. That's also the years I started getting RSI,
| changed a lot of habits, keyboards, postures etc. to come to the
| conclusion that the real issue was plainly doing the same
| movements over and over.
|
| As a data point of n=1, optimizing workflows for maximal
| productivity meant doing the same optimized actions again and
| again, and do them fast. Which wasn't good. Reducing
| "productivity" and introducing more input methods that I can
| switch to here and there when I feel like it helped a lot. So
| less touch typing marathons, less shortcuts, more GUI and more
| variety overall.
| TylerE wrote:
| I got over the productive porn real quick when I figured out
| that given little more than say, line numbers and syntax
| highlighting, the bottleneck is already thinking speed and not
| editing speed.
| userbinator wrote:
| When you're using the keyboard, are you, for lack of a better
| word, very "tense" when pressing the keys? Do you "peck" at
| them with very brief, high-force pulses?
|
| Among those I know who've complained about RSI and the like,
| the common trend I've noticed is how they press the keys ---
| very abruptly and probably with far more force than necessary.
|
| I've been using vi for literally decades so I don't think it's
| to blame. I average 140-150wpm on prose and can type all day at
| that speed.
| makeitdouble wrote:
| Yes, you're spot on. I was using a mildly stiff, mechanical
| split keyboard while having relatively weak fingers.
|
| Stopped using it and switch to a low profile chiclet keyboard
| where I was using way less strength, and could type more
| loosely. It also made it way easier to type on glass, as an
| unintended side effect.
|
| Switching to a trackpad also helped in interesting ways, as I
| got rid of many keyboard shortcuts for page navigation, app
| switching etc. and moved to gestures instead.
|
| To note, I still use vim a lot. Just not as my main editor.
| Also the changes I made are probably very personal and
| wouldn't have the same effect on other people with different
| tendencies.
| doix wrote:
| As a counter data point, I switched to vim precisely because
| constantly reaching for the mouse was causing my problems. I
| switched to a vertical mouse for a while and it helped, but
| still had problems. I switched to a connected split keyboard
| (Microsoft Natural Ergonomic Keyboard 4000) and now use a fully
| split keyboard (moonlander).
|
| Having the keyboard tilted and each half far away so that my
| shoulders aren't rotated inward was a huge win for me.
|
| But I guess when I was using the mouse, I wasn't "slow". I
| would "rapidly" switch from keyboard to mouse as fast as I
| could. The longer it takes me to get something from my head
| onto the screen, the more distracting and exhausting I find it.
|
| Eventually there will probably be neural links, and you just
| think something and it happens. Until then, vim is as close as
| I can get it.
| stainforth wrote:
| Just curious, would/do you do a lot of pinkie stretch movements
| i.e. to hit ctrl? I've remapped using autohotkey ctrl to caps
| lock on my personal computer and its a godsend to bypass this.
| I seriously think this should've been the convention. I wish I
| could enable it on my locked down work laptop.
| TylerE wrote:
| It was, then as usual IBM mucked it up. The only thing worse
| might be the Amiga layout... letter width capslock to the
| left of A, and then a 1.25 width ctrl directly to the left of
| that.
| makeitdouble wrote:
| I did a lot of changes, so which one would have sufficed is
| hard to tell (in exchange I have absolutely no RSI left).
|
| I use keyboards with extra keys so the esc key was always
| mapped pretty near. With IME languages an ESC+language switch
| shortcuts is absolutely needed anyway (at least for vim
| users)
| hbn wrote:
| Worth noting Microsoft actually distributes an "official"
| (quotes cause it was made by an employee seemingly out of
| their own desire, but it's distributed on MS's website)
| program that maps ctrl to capslock. Aptly named, Ctrl2cap [1]
|
| Thought they really ought to just let you do this out of the
| box already. macOS lets you map modifier keys to other
| functions just in the regular old system settings.
|
| [1] https://learn.microsoft.com/en-
| us/sysinternals/downloads/ctr...
| eterps wrote:
| Vim keybindings are like a Huffman encoding for expressing text
| manipulation operations.
| p-e-w wrote:
| When engineers report that switching to Vim has massively
| improved their productivity, I can't help but think that the way
| they work must be very, very different from my own.
|
| When I "program", 95% of what I do is _read_ documentation and
| other technical resources, _conceptualize_ what I want to happen,
| and _construct_ the corresponding logic flow, while trying to
| _anticipate_ potential problems and corner cases. In other words,
| most of what I do doesn 't involve touching the keyboard at all.
|
| If Vim magically tripled the speed at which I'm able to edit
| text, I doubt it would have a noticeable impact on my _overall_
| productivity. In fact, even if you gave me a brain-computer
| interface that allowed me to manipulate text at the speed of
| thought, it wouldn 't matter much. I touch-type at around 70 WPM,
| which is very average, but if I two-finger typed at 15 WPM
| instead I would still be able to produce exactly as much code as
| I do today.
|
| Simply put, text manipulation is not at all a productivity
| bottleneck for me. I need much more time for thinking about code
| than I need for writing it.
|
| Is this really unusual? How do people operate for whom Vim gives
| a productivity boost? Does code just flow from their brains into
| their fingers? I don't get it.
| xeyownt wrote:
| If I would type at 15 WPM, I would be MUCH less productive than
| I am today for sure.
|
| The point of using Vim, is that you boost your keyboard
| interface to the maximum. Obviously, using Vim, means you
| touch-type. Also, you don't use the mouse. Basically, using
| Vim, is like having the brain hard-wired to the computer for
| every task, not only text edition. Everything you do goes
| through the keyboard, and you don't have to think about it. You
| scroll through text, search for it, edit it, open new files,
| etc.
|
| For instance, most of the time I don't use any GUI for Git
| either. I do everything in the terminal, and only use the GUI
| for partial commit (ie. select which line to commit). I have
| dedicated aliases for getting history, etc.
|
| Also, when learning Vim, you notice that many (Linux) tools
| have Vim shortcuts enabled. I discovered many of them by
| chance, out of the habits of using Vim shortcuts.
| p-e-w wrote:
| > Everything you do goes through the keyboard
|
| Except web browsing, which is a huge part of software
| engineering, and which is nearly impossible to do without the
| mouse because most websites cannot be reasonably navigated
| with shortcuts alone.
|
| So the whole model falls apart, really.
| prmoustache wrote:
| Not really and only on a vanilla browser.
|
| Most of my operations on a web browser involve scrolling or
| swapping pages, which I typically do with a keyboard.
| Besides every browser has keyboard extensions that allow
| one to select links through keyboard press. Being a neovim
| user I like vimium on firefox. I also like to use text
| based browsers for a better browsing experience and less
| distraction when I am coding.
| schoen wrote:
| Some avid vim users will also use https://vimium.github.io/
| in their browsers, so they can also browse using the
| keyboard and vim-like cursor movement commands.
| d4rti wrote:
| Tridactyl does the job for most websites pretty well as for
| text heavy sites like documentation it's very good.
|
| https://github.com/tridactyl/tridactyl
| ludicast wrote:
| I don't find myself needing the browser too much when I
| code. Other than to reload a page if I'm tweaking something
| on the FE.
|
| Not that I know everything, but I view informational
| browsing as a distraction while programming. The LSP
| augments most of the knowledge gaps for me.
|
| If vim isn't for you that's cool. But I find other editors
| for me are this-is-fine.gif.
| xeyownt wrote:
| I use trydactyl.
|
| Really, the model doesn't fall apart. But you don't have to
| use it if you don't want to.
| roelschroeven wrote:
| For what it's worth, I have no problem using the mouse, or
| the keyboard, but I hate having to switch between them all
| the time. The longer I can use one without having to switch
| to the other, the better. Editing text can't really be done
| without the keyboard, so for that activity the use of the
| mouse should be absolutely minimal.
| [deleted]
| wruza wrote:
| _read documentation and other technical resources,
| conceptualize what I want to happen, and construct the
| corresponding logic flow, while trying to anticipate potential
| problems and corner cases. In other words, most of what I do
| doesn 't involve touching the keyboard at all._
|
| In my case, this often creates an elegant and conceptual code
| that doesn't match expectations or even reality. Reminds me
| these meetings when someone e.g. says "no-brainer, there's API
| for that" and goes on with requirements, schedules and
| administrative tasks without checking first if it's hooks,
| streaming, polling with a rate limiter, or a non-idempotent
| email-like protocol with a completely undocumented bullshit in
| its payload section. The correct remark is "hold your horses".
|
| More than half of my work (strange corners of fintech) is
| checking, testing, prototyping, fail-refine cycles, unrealistic
| expectation reports. Not only APIs, also hw, niche software,
| reverse engineering, a little bit of everything. 80% of it goes
| straight into the "Attic" repo after few hours. I have to type
| an unelegant and unconceptual code _fast_ and reshape it at the
| speed of thought about a realtime problem, there's no time for
| clever design if a business-critical decision or a paper-heavy
| process depend on these experiments.
|
| Using a boring editor feels like you want to quickly visit a
| few places to see if they are good enough, but they are all in
| different cities, so you start to forget details while you
| drive. And relying on a documentation is like buying a house by
| pictures alone.
|
| For me the structure comes from the actual code, after I can
| extract its true shape, after the requirements got satisfied in
| a fully functional prototype, which is also a sort of a
| knowledge base for a project. I'm able to plan it in advance,
| but only with 20% probability and 80% of unnecessary work.
| helaoban wrote:
| For some (myself included) the high speed and efficiency of
| proficient modal editing serves as a thinking aid, like
| sketching with a pencil and eraser. I tend "play" with the
| code: chopping it up; splitting lines and inserting a bunch of
| white space; duplicating lines dozens of times to act as
| placeholder values (e.g filling an array literal); renaming
| variables across a file many many times before settling on the
| right name; moving helpers functions to the top, then to the
| middle, then next to their first invocation etc.... All doable
| with other editing styles, but at a higher cost, and the cost
| of manipulation has to be very low in order to reap those
| meditative qualities.
|
| Manipulation far outweighs input. And manipulation is
| fundamentally thinking, at least for me.
| Aperocky wrote:
| Great point, /SEARCH_TERM and n is extremely useful for
| finding stuff and understanding. also when you screw up
| either because muscle memory went haywire or the logic looks
| bad then just uuuuu until the status bar (plugin) show no
| change since last save.
| worksonmine wrote:
| If your goal is to return to the state where you opened the
| file ":earlier 10m" might be more useful than spamming u.
| p-e-w wrote:
| As opposed to other editors, which don't have shortcuts for
| search and undo?
| probablynish wrote:
| This is a great point that I never thought of. Seems like a
| general example of the idea that lowering the cost of some
| action sufficiently low can lead to not just efficiency gains
| in areas where that action is currently used, but also new
| and surprising uses of that action.
|
| For example, I once read an economics book that characterized
| computers as lowering the cost of integer arithmetic by an
| extreme amount. That led to things like digital
| music/pictures - no-one would have previously thought of
| using a ton of numbers to represent a song - not just
| efficiency gains in accounting.
| thwarted wrote:
| > no-one would have previously thought of using a ton of
| numbers to represent a song
|
| Music has long been represented using math and math
| concepts. Musical notation is a cartesian plane with time
| on the x-axis and pitch on the y. But that's the
| representation, and it's not about the representation, it's
| the ability to manipulate at extremely high speed.
| probablynish wrote:
| I see what you're saying, but musical notation isn't a
| precise representation of the audio. Given the same
| score, two musicians can produce very different
| interpretations. Perhaps I should have said 'audio'
| instead of 'song'. (I took classical piano exams as a
| kid, and at some point a group of us would perform our
| prepared pieces for each other as practice, and I
| remember always being surprised at how different
| everyone's pieces sounded. I'd thought mine was the One
| True Way!)
| fierro wrote:
| totally agree. Also, when developing in complex codebases,
| being able to shorten the time distance between thinking an
| action needs to be done and actually doing it means you can
| keep more ideas in your head rather than spend your CPU
| cycles on visually moving around your screen, clicking,
| waiting, etc.
| mannykannot wrote:
| Personally, when I find myself doing the things you mention,
| I realize it's time to back off and refocus on the things
| mentioned in p-e-w's second paragraph. In that state, I feel
| I am fidgeting with the code, and it is probably because some
| unresolved issue is blocking me.
| 5e92cb50239222b wrote:
| All of that can be done in JetBrains' IDEs with a single
| hotkey. Especially stuff like code extraction or
| variable/class/function renaming -- it actually works
| reliably across the whole project (not just a couple of
| files) even if you have multiple functions with the same
| name. Extracting code to variables/constants/functions also
| works reliably (like automatically adding referenced data as
| function arguments).
| techwizrd wrote:
| I tend to use Vim/NeoVim regularly, and I really enjoy
| using IdeaVim when I use JetBrains' products. I get the
| fast modal editing and the IDE refactoring features. It's
| the best of both worlds.
| kqr wrote:
| Yes, but does it work the same way in Shell scripts, Ada,
| Haskell, Perl, Python, C#, screenwriting, and
| documentation?
|
| The power of text-based manipulation is that you don't have
| to learn a different set of hotkeys for different types of
| material.
| probablynish wrote:
| IntelliJ (the canonical JetBrains IDE) has plugins for
| the first 6 of those - so at least for those, it _does_
| work the same way. The hotkeys to perform the actions
| mentioned in the parent comment don 't change.
| kqr wrote:
| TIL! There weren't so many language plugins last time I
| tried it, so I felt like I had to drop back into
| Emacs/Evil fairly often. Good to know that's not as much
| the case anymore!
| 5e92cb50239222b wrote:
| Yes, and also in CSS, SQL, ocaml, Rust, and a million
| other languages. Navigation works reliably (including
| cross-language navigation: for example, you can easily
| jump from a CSS class mentioned in HTML or JSX to its
| definition even if it's has a very generic name and is
| defined in a random file far away). Even if it has a
| complicated definition using something like SCSS and is
| simply not greppable.
|
| Or do the reverse -- find all usages of a CSS class from
| its definition (again: do so _reliably_ , it's not a
| simple grep).
|
| Find all references to a particular database column (in
| SQL queries across the project, foreign keys in other
| database tables, and ORM models)? Same hotkey.
|
| Stuff like code selection works reliably since IDE work
| with code on an AST level and you're asking it to select
| the current AST node (and not the "current text block"),
| going up the tree as needed.
|
| And so on.
| p-e-w wrote:
| > The power of text-based manipulation is that you don't
| have to learn a different set of hotkeys for different
| types of material.
|
| And the weakness of text-based manipulation is that it
| views code as characters rather than as semantic data.
|
| Modern IDEs either have their own semantic code
| operations, or use language servers to actually
| understand the code rather than just work with character
| strings. This is _vastly_ more reliable when doing
| refactoring or project-wide navigation. Text-based
| approaches are a crude hack by comparison.
| fileeditview wrote:
| In Vim you also have plugins that provide you with
| semantic editing (e.g. via LSPs). You then have it both..
| same as if you installed a Vim plugin in your IDE. The
| only difference being that the IDE is slow and has a
| multitude of features that I don't need whereas Vim is
| configured to exactly my needs and has instant response
| always.
| probablynish wrote:
| Would you say that a vim plugin in your IDE of choice
| gives you the best of both worlds? The superior semantic
| manipulation of an IDE and the superior text manipulation
| of vim.
| l3uwin wrote:
| [dead]
| bostik wrote:
| > _Is this really unusual? How do people operate for whom Vim
| gives a productivity boost?_
|
| Don't think of vim as a magic totem of productivity. You should
| think of it as a largely _distraction-free_ editor. No messing
| about with a mouse. No GUI to get in the way of your thoughts.
| Loads up immediately, and works the same way in any system,
| local or remote.[ss]
|
| So it's less to do with speed of writing, and much (much!) more
| about maintaining focus.
|
| ss: not really true, any long-time user will have their own
| customisations they rely on, but the basic commands are always
| the same.
| stcroixx wrote:
| Agree so much. It's such a tiny fraction of the time spent for
| me no amount of optimization would affect the overall timeline.
| rewgs wrote:
| It's flow state/reducing cognitive load, not just literal
| typing speed. I know that might sound insane --- I was
| extremely weary of such claims for a long time and thought vim
| was stupid --- but after getting over the "hump," I get it and
| absolutely can't go back.
| flohofwoe wrote:
| I fully agree. Yet I still learned the vi input model because
| pretty much every text editor on every platform supports it one
| way or another, and a cross-editor / cross-platform input model
| makes it a no-brainer to switch editors (which I do all the
| time, e.g. using vim for quick edits on the command line, and a
| 'proper' IDE for coding, where the IDE also changes (VStudio,
| Xcode, VSCode) depending on platform or task at hand. And while
| typing speed doesn't matter much for productivity, "muscle
| memory" does for "staying in the flow".
| goodpoint wrote:
| > text manipulation is not at all a productivity bottleneck for
| me
|
| No, but the benefit is in the mindset encouraged by Vim,
| especially around modal editing.
| BrS96bVxXBLzf5B wrote:
| I agree with your point but fwiw when I worked a full time C
| job doing things with servers running a custom Linux kernel the
| biggest conveniences were Shift+k over a keyword to open the
| man page (most of my time was reading docs too!), having some
| custom scripts that read ctags and could tab-complete keywords
| from our large codebase and open the files at the right line,
| and having the same editor on our embedded servers and VMs as
| on dev machines (and even now that's half of why vim is still
| my primary).
|
| There were people at the company who were more efficient than
| me using Sublime + mouse, but I was less efficient using
| Sublime.
|
| (but really the biggest reason I use vim as a slow and sloppy
| typer and not a computer person is, hotkeys make my hands hurt,
| I've managed to avoid any RSI or pains like this, and I like
| vim better than vim keybindings in other editors.)
|
| other productivity gains not related to typing were the
| search/replace in vim, embedded terminal, and being in and
| staying in a terminal made it easier and quicker to switch to
| scripty things, searching or reformatting files etc
| p-e-w wrote:
| > Shift+k over a keyword to open the man page
|
| Any widely used modern editor/IDE will have plugins to do the
| same thing.
|
| > having some custom scripts that read ctags and could tab-
| complete keywords from our large codebase
|
| Contextual completion as offered by modern IDEs or language
| servers is vastly superior to Ctags, and you don't have to
| home-cook anything to get it working.
|
| > and having the same editor on our embedded servers and VMs
| as on dev machines
|
| That's what SSHFS is for. No need to limit yourself to
| whatever happens to be installed on the remote machine. You
| don't even have to copy config files around.
| BrS96bVxXBLzf5B wrote:
| okay? you've pivoted from "not understanding" vim to having
| an anti-vim boner. other people in the same environement
| achieved as much or more than me with different tools. and
| those different tools didn't work for me. that's all that's
| going on here.
|
| (sshfs is not a direct substitute for being able to quickly
| interact with a remote environment)
|
| > having some custom scripts that read ctags and could tab-
| complete keywords from our large codebase
|
| for clarity i meant that I had a completion in the terminal
| when not in the editor to quickly jump to a tag in a file.
| `vim -t <keyword>`. i could be in a terminal, execute a
| remote command on a machine, know what I wanted to look at
| next and quickly go there without much effort. And again,
| other people were productive without doing this. these were
| just my tools and i liked them.
| jononomo wrote:
| "Does code just flow from their brains into their fingers?"
|
| Honestly, it does feel that way sometimes. You move so much
| faster and with so much more efficiency and power that you can
| just think at a higher level while you're coding.
| mrjin wrote:
| I guess it might be because the nature of your work. When I
| started as a SE over a decade ago, my job was really just
| writing code according to the specs. Typing speed was important
| as I wrote over 100k lines of code in the very first year. But
| less and less code I wrote after that. Once I spent around 6
| months meeting CEO daily just to figure out what was wrong with
| something screwed pretty badly by someone with a fancy big
| title. Eventually the code I changed to fix those problems were
| less than 30 lines. That was extreme, but on average, I hardly
| write more than 100 lines of code per day just like you. Typing
| was no more an issue for a very long time.
| gmadsen wrote:
| 10k lines is still 10k lines. What I like about vim is that it
| mimics how i think about code, its the closest thing to a brain
| interface that an editor can be.
| throwaway_au_1 wrote:
| It sometimes seems like a lot of the _Vim, ew_ crowd think that
| the sole reason for using Vim is gaining some kind of god-like
| ability to physically pump out and manipulate characters. Sure,
| maybe that 's possible. For me, it's about being efficient with
| my keystrokes. Standard shortcuts (Ctrl+_) are pretty
| unpleasant for my hands - saying this having already mapped
| CAPS_LOCK to LEFT_CONTROL (and LEFT_CONTROL to ENTER). I like
| running commands using sequences of letters - it just feels
| physically easier to me than sequences of multi-key-presses
| (e.g. Ctrl+Shift+T). That Vim has other smarts around that is
| just a perk.
|
| Editing text using Vim, once you've built the muscle memory,
| really feels super natural and effortless. I really hate
| reaching for the mouse; it just irks me in a way that's hard to
| describe. Similarly, editing code without Vim feels tedious in
| a similar way. Imagine scrolling a long article by pressing the
| down arrow over and over, or clicking the down button at the
| bottom of the scroll bar.
|
| Another complaint I see is that remembering the commands is too
| hard an ask. I moved from QWERTY to Workman at the same time
| that I was learning Vim and it was interesting because I
| learned that I -- and probably most people, but I'm speculating
| -- don't associate commands or actions with letters after
| they're initially learned. It's all muscle memory, just
| particular movements of select fingers. The Vim stuff you use
| day-in-day-out just sticks in your brain and you don't think
| about anymore than you think about which fingers to activate to
| type words.
|
| Of course, some people probably just prefer to edit text like
| they do in almost all other text-editing contexts. They can
| already edit text; without some kind of perceived extra value,
| there's no motivation to change, or seemingly even try to
| understand an alternative. For me, it's the pleasure of feeling
| efficient and doing dev pain-free.
| fileeditview wrote:
| Yep there are many more reasons than "typing fast" for using
| Vim. For me the main motivator to dive into Vim was to not
| use the mouse at all because it constantly gave me RSI. It
| worked great. I never again had RSI since I switched to Vim
| for all my coding.
| jerf wrote:
| "If Vim magically tripled the speed at which I'm able to edit
| text, I doubt it would have a noticeable impact on my _overall_
| productivity. "
|
| It's an Amdahl's law thing. Even if you drop my typing time
| down to zero, it wouldn't affect much. That said, multiplying
| my typing time by 10 would be a hit.
|
| I consider being bottlenecked on my raw ability to type to be a
| _huge red flag_. I 'm doing something wrong unless I have a
| very specific reason to be so bottlenecked, like I'm
| momentarily just doing data entry with no ability to simplify
| the process. (Unusual, but it does happen; for a micro example,
| typing out all of some enumeration's value can bottleneck on
| raw typing speed if there's more than a couple of them and I
| happen to be able to instantly and correctly name them all.)
| Must be missing an abstraction or something.
| zokier wrote:
| Fast typing speed and efficient editor practice are
| transformative; when human-computer interface becomes
| frictionless you unlock notation as a tool of thought, and
| really be able to use the computer to design your programs
| instead of doing design first in your head/pen-and-
| paper/whiteboard and then transcribing near-final code to
| computer. Or at least that is the idea; I'm not 100% certain if
| it is not just pipedream for majority of us.
| koonsolo wrote:
| I work differently. I mainly read code, and do small
| manipulations in different places. Reading technical
| documentation is maybe 5% of what I do. I mainly need to figure
| out code.
|
| So basically it's jumping around, refactor some stuff, and add
| some stuff. For that, Vim is ideal.
|
| Code only flows straight from brain to fingers when it's
| trivial and boring ;).
|
| I use the VSVim plugin in VSCode. I wouldn't necessarily call
| it a "productivity boost", but more of a convenience or
| ergonomic solution.
|
| The Vim keybindings make it really easy to for example copy
| something within () and then navigate quickly and paste it
| somewhere without touching your mouse.
|
| But overall I agree, I can probably do the same amount of work
| without the Vim plugin, it would just make it more
| inconvenient: more mouse manipulations, ctrl-shift-arrow finger
| spreadstands to select chucks of text etc.
| jatins wrote:
| I'll tell you my motivations to switch to Vim. My wrists.
|
| All that typing in 20s finally caught up and I have been having
| recurring wrist pain.
|
| Keeping fingers near the home row as Vim keybindings encourage
| and avoiding jumping around on keyboard in one way to avoid
| wrist strains and something I'd recommend people to start doing
| earlier rather that later.
| Panzer04 wrote:
| I think it's rarely a productivity bottleneck, but that doesn't
| mean that Vim keybindings and navigation aren't superior in the
| vast majority of cases to what most people are doing - which is
| scrolling, mousing about, etc. Vim keybindings significantly
| accelerate the editing and browsing of existing code in-editor.
|
| It also has the convenience of being a fairly common set of
| keybindings in editors nowadays, as many have an extension that
| gives Vim keybindings without having to go all-in on a CLI-
| style Vim editor.
| p-e-w wrote:
| Every modern code editor has character-, word-, subword-,
| line-, and page-based navigation, as well as "jump to symbol"
| functionality. Bookmarks, paragraph navigation, and similar
| are also very common.
|
| I fail to see how Vim is supposed to be superior to that. It
| has essentially the same navigation features, with different
| keybindings. And the idea that those different keybindings
| are somehow "better" is a big _[citation needed]._
| Panzer04 wrote:
| How common are the keybindings used in existing editors? I
| must admit I haven't ever really noticed the
| hotkeys/keybindings in editors - until I started using Vim
| bindings instead. There's likely a large crossover between
| people who use a lot of hotkeys and people who look into
| learning something like Vim. If they change often across
| editors, it wouldn't surprise me that they aren't often
| used, so don't get much evangelism compared to Vim (which
| has been more or less the same for decades)
|
| I only use a small subset of Vim's shortcuts - but most
| text editors I've used I'd imagine don't have the breadth
| Vim does (or they do a really poor job of documenting it).
| Can you point out a doc page for some IDE with similar
| navigation capabilities to Vim?
| p-e-w wrote:
| > How common are the keybindings used in existing
| editors?
|
| The whole point of widget toolkits is that the
| keybindings for input fields are the same _everywhere._ I
| use Linux and almost exclusively run GTK-based apps, and
| every text input across the whole system behaves the
| exact same way, with consistent keybindings for
| navigation, undo /redo, copy+paste etc. This is how good
| UI should work.
|
| Platform conventions are important, and it's the job of
| individual programs to adapt to them - not the other way
| round. Vim fails big time in this regard. Can you make
| Firefox's form inputs use Vim keybindings? If not,
| there's your inconsistency already.
| xeyownt wrote:
| > Platform conventions are important, and it's the job of
| individual programs to adapt to them - not the other way
| round. Vim fails big time in this regard. Can you make
| Firefox's form inputs use Vim keybindings? If not,
| there's your inconsistency already.
|
| I disagree with that. And the world doesn't have to be
| perfect.
|
| If you use Vim and you like it (it takes LOT of effort),
| you will adapt the platform to the Vim ways whenever
| possible. Everytime I encounter something I cannot vim-
| ize, I'm pissed but I have to put up with it. It's like
| working with Windows.
|
| For the browser, you can use Vim binding for navigation,
| and edit with Vim. But again, this is not mandatory per
| se to benefit from Vim as a developer.
| [deleted]
| kovac wrote:
| > Can you make Firefox's form inputs use Vim keybindings?
|
| Do you mean something like this:
| https://github.com/glacambre/firenvim?
| p-e-w wrote:
| Yes, but I mean without an ugly hack that involves
| spawning a process every time you want to edit a browser
| text field.
| worksonmine wrote:
| It's not an ugly hack, it's about not reinventing the
| wheel. Pure js solutions also exist but they're a subset
| of the features, and using native vim gives you the
| benefits of plugins you already have on the system.
|
| It's a feature, and it follows the unix philosophy. But I
| get that not everyone needs or wants it.
| ablob wrote:
| "Yes, but ..." is a great way to move your goalposts.
|
| On another note, do you expect your hotkeys from your
| Office program to work in a Firefox form field?
| unsignedchar wrote:
| vim has had these keybindings/controls as primary features
| for decades, and people that have these in their muscle
| memory the benefits have accrued over a long time and a
| number of different platforms.
| twobitshifter wrote:
| All of those keybindings are not composable, vim is. you
| can find with a shortcut, but vim can "dtr" to delete all
| text up to r. or maybe you want to delete 3 lines, 3dd will
| do that. Once you recognize vim is like a language for
| editing, you'll get it.
| worksonmine wrote:
| Not a scientific source, but there's probably a reason
| behind the popularity of evil mode for emacs, and vim
| plugins for just about anything (yes I know emacs is often
| the default, but that's for practical reasons like Ctrl+a/e
| is easier to add than 0/$).
|
| My pinkies love me ever since I started using vim. For me
| it's not the specific keybindings, but the modal editing
| allow more uses for the same keys depending on context and
| less need for modifiers.
| PurpleRamen wrote:
| > When I "program", 95% of what I do is read documentation and
| other technical resources
|
| That's very off from my work. For me, it's the opposite: 95% is
| writing code, navigating code, testing code or doing stuff in
| the shell. Reading documentation usually makes only a small
| amount. And even then, writing notes makes a good part of it
| too.
|
| > conceptualize what I want to happen, and construct the
| corresponding logic flow, while trying to anticipate potential
| problems and corner cases.
|
| I can also do that while typing. Mindgears are no reason to
| stop typing.
| jhoechtl wrote:
| Only tangentially touching your points, my take on Vim or modal
| editing in general is the following:
|
| When I edit existing text (program code, prose) a modal editor
| shines. I am mostly in command mode and re-arrange text or re-
| factor code from here to there.
|
| When I am _creating_ text, for me a modal type editor is a
| hindrance. Agreed, I should probably be most of the time in
| insert mode yet in practice I find myself switching between
| insert mode and command mode all the time. For what reasons
| ever this switching never made it into "muscle memory" and
| disrupts my workflow.
|
| For that reasons I am an avid user of both Vim and Emacs.
| doix wrote:
| > Is this really unusual? How do people operate for whom Vim
| gives a productivity boost? Does code just flow from their
| brains into their fingers? I don't get it.
|
| I am very bad at keeping all that stuff in my head at once. I
| need to get things out of my head onto the screen as fast as
| possible, so that I can then think about the "next step". Then
| I need to be able to quickly refer back to many places quickly
| and switch back and forth between different places in the
| codebase.
|
| For example, as soon as I think of a corner case, I'll try to
| handle it immediately in an if statement or something. Then
| it's there, in the code. Maybe it stays in the final version,
| maybe I end up with 10 if statements and need to refactor
| everything.
|
| But it's much easier for me to do that when everything is
| written down in the code rather than trying to do it all in my
| head.
|
| If I typed at 15 WPM, I'd probably be easier to just reason
| about it in my head, because by the time I finished typing, I
| would have forgotten what I was thinking about.
|
| I'm sure these things cause a feedback loop of sorts. Because I
| know I can get stuff out of my head quickly, I don't bother
| training myself to get better at storing more in my head at
| once. So I get worse and the solution is just to edit text
| faster.
|
| Similarly, I suspect since you can keep everything in your
| head, there's no incentive to get faster at editing text. And
| if a problem is "harder" the solution is to get better at
| keeping stuff in your head.
|
| I don't think there is a right or wrong answer. I think
| exposing people to both sides is important, so they can find
| what works for them.
| martindbp wrote:
| > Simply put, text manipulation is not at all a productivity
| bottleneck for me
|
| I once believed this and this comment could have been written
| by me verbatim. But I decided to seriously give vim a try and
| I'm still very happy 8 years later. I don't know for sure that
| vim makes me a better programmer, but going from vim to another
| editor is a bit like going from your large desktop screen to a
| 13" laptop working at a cafe. I can do the work but it's just
| slower and not as enjoyable.
|
| Maybe it's not so much vim specifically, although I enjoy the
| modal editing part, but just 100% investing in a single editor
| and getting really good at navigating and editing code with it.
| It's always fast and responsive and always available. Before
| vim I used different editors for different jobs, Emacs, BlueJ,
| Eclipse, Visual Studio, Sublime, XCode etc and I never truly
| invested in any of them. Once you make a decision to just use
| the one editor, it's a powerful thing.
| alwillis wrote:
| > Simply put, text manipulation is not at all a productivity
| bottleneck for me. I need much more time for thinking about
| code than I need for writing it.
|
| For simple things, there's no perceived bottleneck in any
| editor... but not everything is simple. The productivity gains
| come from being able to make complex changes to documents using
| just normal mode and ex commands, which would normally require
| macros, scripts or plugins in other editors.
|
| For example, this 12 year-old video by Derek Wyatt [1]
| demonstrates extracting the text from a XML representation of a
| mind map and turning it into a hierarchical, bulleted list
| using Vim's search and replace commands which support regular
| expressions. Attempting to do the same thing in Notepad for
| example might take you 15-20 minutes.
|
| He has a series of these videos, some of them jaw-dropping
| showing the power and brevity of using Vim for non-trivial
| editing and data extraction tasks.
|
| And remember--this is Vim from 12 years ago with zero plugins.
|
| > Does code just flow from their brains into their fingers? I
| don't get it.
|
| There's a reason why the subtitle for Drew Neil's book
| _Practical Vim_ is "Edit Text at the Speed of Thought" [2].
| It's probably the best book on Vim that illuminates the power
| and efficiency of Vim and why it matters.
|
| One you attain a level of proficiency with Vim, as you think
| about what to do next, your fingers hit the right keys and
| without thinking about it, the change is done.
|
| An identifier for a constant needs to be all caps? Say the
| cursor is at the end of the line and the identifier is at the
| start of the line and I'm in insert mode.
|
| 1. Press Escape (enters normal mode)
|
| 2. Press '0' (motion for jump to first character of the line)
|
| 3. Press control-v (enter visual block mode)
|
| 4. Press 'e' (move the cursor to the end of the word while
| highlighting the word)
|
| 5. Press '~' (switches the case of the highlighted characters)
|
| There's no reaching for the mouse or moving your hand towards
| the trackpad from the keyboard. It may not seem like much, but
| for experienced Vim users, an operation like this is a second
| nature, muscle memory thing that takes about a second to do.
| There's no break in focus or concentration and you're off doing
| the next thing.
|
| That's where you save time and editing becomes more efficient.
| And while there are dozens of these types of simple edits that
| second nature to Vim users, doing more sophisticated changes
| can be just as efficient.
|
| [1]: https://vimeo.com/user1690209
|
| [2]: https://pragprog.com/titles/dnvim2/practical-vim-second-
| edit...
| amphrony wrote:
| [dead]
| Zacharias030 wrote:
| I have mapped esc+hjkl to arrow keys system-wide and moved
| esc to capslock, which is a already a game changer.
|
| The respect for vim and especially vim keybindings is
| definitely there, I use it for editing bashrc's or similar or
| inspecting stuff in the terminal, but what do you recommend
| to get over the hump of learning it better such that e.g.
| vimbindings in vscode could replace the standard?
|
| For code, I use vscode currently, so your example would be:
|
| * cmd capslock h (to go to the beginning of the line)
|
| * alt capslock l (to move right to the first word and off the
| whitespace)
|
| * cmd d (to highlight the word und the cursor)
|
| * F2 to rename the symbol codebase-wide or cmd shift g to
| select all occurrences in the file
|
| * retype the word in allcaps (enter if F2 was used)
| DennisP wrote:
| It was a huge productivity boost for me, because when text
| editing was tedious, I would lose my flow, get bored and
| annoyed, and start goofing off.
| jiki wrote:
| Same here. My productivity gain mainly comes from my brain, not
| how fast I can type.
| triceratops wrote:
| Or, as Steve Yegge put it, most programmers are CPU-bound
| rather than I/O bound.
| jcalvinowens wrote:
| I love vim. I've been using it for almost 20 years now.
|
| I agree with you about code entry speed, that's not the point.
|
| I think the easiest way to put it is that vim is 0% task
| loading. I never have to expend any energy dealing with it,
| making it do something I want, finding some button that moved
| around, etc. Vim just works: in almost two decades, I have
| never once encountered a single bug or change in behavior that
| I found irritating. Seriously, never. I just write code.
|
| 99% of the code I have written both personally and
| professionally in my lifetime was written in vim. That's the
| other win for me: all that muscle memory is still beneficial,
| now and forever. Its a much more universal tool than any IDE.
| Aperocky wrote:
| Do you write config files? Do you copy similar unit test
| structures? or perhaps have you ever found a mouse/touchpad
| annoying?
|
| If purely going off programming speed, probably won't improve
| much. Most of the time is spent thinking. But it helps reduce
| annoyance in many other situations - I'm not annoyed when I
| think, but I'm annoyed when I have to move the cursor, drag it
| and do it 10 different times when in vim the same is burned
| into muscle memory and can be done without any thought process,
| over some config file that I must edit now but not that often
| enough that it's worth creating a script or template, and then
| the same apply to templates as well and all levels of
| abstraction.
|
| An extremely common scenario is to copy the content from one
| enclosed parentheses and into another, and similar class of
| problems. With vim it's just a few keystrokes, but without it's
| lots of cursor and drag. These common scenarios are why people
| use vim bindings.
|
| Oh and I can do all of that in the terminal of a remote
| machine, which happen to have enough memory to run a massive
| integration test, and build all things a lot faster.
| swah wrote:
| I'm one of those that knows a good deal of Vim and Emacs, and
| moved to VSCode and felt things just work better there.
|
| The pattern nowadays for me always goes like this:
| 1. Let me try Vim again. I do miss that kind of efficiency
| 2. This is so fun, I really missed it (for a few minutes or
| hours) 3. And then *one little comfort* from VSCode is
| missing... and I'm back on VSCode for months.
|
| Maybe if my brain could just accept that one can edit the same
| set of files on two editors at the same time, it would be the
| best way to work.
| aezart wrote:
| I've been using vim for the last 6 years because most of my early
| projects at my job involved PuTTY-ing directly to Solaris and
| RHEL servers to do dev work (mostly shell scripting and PHP).
|
| I don't do anything particularly sophisticated with it; recording
| macros to repeat the same transformation on multiple lines is
| about my limit. But I _love_ being able to work with my hands
| permanently on the home row of the keyboard, and having to switch
| between keyboard and mouse with other software feels like a chore
| now.
|
| Sadly these days I mostly make Mulesoft applications using
| Anypoint Studio. I still use it for most of my text editing at
| home at least.
| SapporoChris wrote:
| Vim use can cause increased irritability and aggression? Yes,
| that makes sense. https://nida.nih.gov/publications/research-
| reports/steroids-...
| H4ZB7 wrote:
| [dead]
| behnamoh wrote:
| My Vim experience got much better when I added this to my config:
| vim.keymap.set("n", "<leader>sr", ":%s//")
|
| It search-and-replaces all occurrences of the word under the
| cursor.
|
| I also added the following to remove the highlights that appear
| (e.g., when pressing *): vim.cmd("nnoremap
| <silent> <c-c> :nohl<CR><C-l>")
| Graziano_M wrote:
| Try mapping it to `:set hlsearch!`. That way you can use the
| same mapping to toggle it on and off as you wish.
|
| EDIT: Also, you can use vim.keymap.set, no need for a vim
| command, just `vim.keymap.set("n", "<c-c>", "<cmd>set
| hlsearch!<CR>", {silent = true})`
___________________________________________________________________
(page generated 2023-01-13 23:02 UTC)