[HN Gopher] What Is Vim?
___________________________________________________________________
What Is Vim?
Author : sauercrowd
Score : 113 points
Date : 2024-12-14 23:06 UTC (23 hours ago)
(HTM) web link (blog.jonas.foo)
(TXT) w3m dump (blog.jonas.foo)
| tom_ wrote:
| I guess. Wake me up when you can enable Emacs mode in vim.
| MrMcCall wrote:
| "A dream to some ... a nightmare to others!" --Merlin, from
| Excalibur
|
| ;-)
| hashkb wrote:
| But why? The best thing about vim is normal mode. Emacs with
| evil-mode is so cool.
| lambda_lord wrote:
| Helix uses a selection-first action model: you select the
| word/paragraph/whatever you want to perform an action on, then
| you change/delete/whatever on that selection.
|
| I think this is more intuitive than the "verb object" model Vim
| uses: if you get your selection wrong in Vim, you then need to
| undo the action and try again. In Helix, I can see what I am
| about to manipulate before I make the action.
|
| I think at this point Vim wins out for being so ubiquitous, but I
| wish the Helix model took off first.
| drekipus wrote:
| That's what I really enjoy about helix (and kak) - a different
| approach to the modal editing paradigm.
|
| I'm still stuck on neovim for now, but progressively I'll make
| my way to helix I think.
| sprobertson wrote:
| I use both in vim - if the selection is tricky use v or V to
| define the selection first, but most of the time "verb object"
| makes sense to me since that's how english works (tho could see
| it being unintuitive for non-SVO languages). "delete the next
| word" or "change inside the parentheses" roll off the brain and
| into the keyboard
| tom_ wrote:
| I remember thinking roughly the same thing when I was a regular
| vim user. This was a long time ago now, so I forget the
| details, but from memory I used to use visual mode quite a lot,
| meaning I'd get to use the motion commands to select the region
| of interest first and then choose the operation to perform on
| it.
|
| The typical vim model is a bit weird, but once I got practised
| with it it was actually quite surprising how much complicated
| stuff I could do purely by sight. But while the muscle memory
| aspect got me further than I'd have expected, it did only get
| me so far. Selecting the region first always seemed like it'd
| be the better way in general, being no worse when your fingers
| can do it automatically, while being better in the case where
| you're having to think about what you're doing.
| srik wrote:
| To achieve something similar in vim one could use visual
| selection first and then run the verb on it. Helps with
| spotting mistakes or just tweaking selections in general. It is
| a tad bit tedious but a small bonus is `gv` which invokes the
| previous visual selection at a later point. That said selecting
| first isn't perfect because large selections often move the
| viewport around especially on small screens and that's really
| annoying but ahh that's life, always with the compromises.
| ericjmorey wrote:
| The lead of NeoVim indicated that it would be possible to make
| this "grammar" an option for users. He didn't seem like it was
| something that's high priority, but he definitely was open to
| PRs to implement it.
| toenail wrote:
| Huh, you can do visual selections in vim as well, and
| manipulate what you selected.
| animal_spirits wrote:
| yes it works the same but for example in vim you do 'delete-
| inner-word' rather than `inner-word-delete`. The selection
| first model allows you to see what you are going to affect
| before you perform some verb on it.
| skydhash wrote:
| I once wanted to try that, but I'm familiar with vim enough
| that these kind of manipulation is done without even
| thinking about it. Only visual line mode proves useful when
| I need to yank/delete whole sections.
| eviks wrote:
| No, you can't, vim visual mode always extends the selection,
| so moving by two words would select two, not the last one,
| but to see how it's different the best way is to just use the
| visual-first editor a little bit
| Lio wrote:
| This strikes me as the difference between English and
| Esperanto.
|
| You wouldn't design English as the international language but
| that's what it has evolved to be.
|
| You can still learn Esperanto as a hobby but it's not going to
| be as useful day to day as English.
| dzsekijo wrote:
| I've set up myself once to learn Helix. First there was Kakoune
| that sounded exciting with its new modal model, but what had me
| wanting to really give Helix a go, beyond being exciting, was
| that it advertised itself "batteries included". It promised to
| deliver all the cool things programmers' editors do recently.
|
| But then I stopped abruptly when realized Helix misses a key
| feature of Vim: swap files. I can just start editing and have
| not have to worry about losing my work, may whichever of
| computer panic, computer running off charge, environment
| (desktop env or tmux) crash, etc. occur.
|
| So edit semantics is cool, but fundamentals like recovery
| should be got right before being a serious contender.
|
| (I did a quick search to see if there is any news on this
| front, but what I found is all about "recovery hooks for
| panic", which is far more less than what's needed - it's about
| an emergency saving of the work if something goes awry with the
| editor. I need to be protected from loss if something goes awry
| with the environment too...)
| wonger_ wrote:
| Does anyone else use swap files? Personally, I find them
| annoying. Saving every time I leave insert mode is my
| preferred alternative: `autocmd! InsertLeave * silent!
| update`
|
| Perhaps helix has something similar?
| WhyNotHugo wrote:
| Helix splits the "select" and "verb" portions into two separate
| actions, so you can't easily repeat the last whole action
| (which you can do in Vim by pressing the dot key).
|
| Which one is more intuitive is probably subjective, but
| personally, I find "dip -> delete inside parenthesis" far more
| intuitive (and closer to my line of thinking) than "select
| inside parenthesis. delete selection".
| mmahemoff wrote:
| Learning Vim early on had a high return on investment for this
| reason. Years later, I'm still able to benefit from the same
| muscle memory in modern tools, e.g. Obsidian.
|
| It should be said, though, that most implementations are
| simplified rewrites of Vim's core functionality. When you use a
| tool to achieve a sense of "flow", it can be grating for the
| editor to behave in subtly different ways from expectation, or
| discover an important feature does not work at all. Also, there
| tends to be limited, if any, support for Vim plugins.
|
| In the modern era of Vim and NeoVim, it's possible for such tools
| to use the real version via network protocol, but integration is
| easier said than done. So far it's mostly been Vim GUI wrappers
| that leverage the capability rather than independent editors.
|
| I still use Vim mode where I can even if it's a shadow of the
| real Vim experience. It makes life easier to use the same muscle
| memory on every shell, editor, and command-line, and not have to
| worry about learning every new app's idiosyncracies.
| dylan604 wrote:
| Long ago, I learned video editing on a CMX tape based system.
| The key bindings on that system remain in place in pretty much
| every video application today. (Spacebar => play/pause, j/k/l
| => reverse/stop/forward, i/o => in/out) Sometimes, keybindings
| just make sense and for them to not do it definitely as you say
| feels disturbing. For new apps that don't, it's like did you
| live under a rock in a cave and never see any other preceding
| program that you are making, or do you honestly think yours is
| better. I can assure, they aren't.
| nyrikki wrote:
| Never touched a CMX, with the EditDroid being the oldest I
| ever saw and it had a trackball/scrub knob.
|
| But the vi keybindings are directly from the LSI ADM 3A
| terminal, which is what Bill Joy wrote vi on.
|
| It had overloaded hjkl for the arrow keys compared to it's
| predecessors like the 7700A and successor 3A+ that had
| dedicated arrow keys.
|
| The fact that Home/~ were the same key thus ~ being your home
| directory and that esc was where the tab key is on modern
| keyboards explains a lot about the vi keybindings.
| chrismorgan wrote:
| > _There 's a Vim mode in every single mainstream code editor out
| there._
|
| And they're always frustratingly incomplete and/or buggy. Some
| motions will be unimplemented, or will behave incorrectly,
| especially with regards to boundaries around whitespace inclusion
| or exclusion in a motion. Things you added to Vim and got used to
| are unavailable, and so your _ysa ")_ to put parentheses around
| the string your cursor is on just doesn't work. (Lack of vim-
| surround definitely gets me frequently.)
|
| In VS Code, it maintains its own undo stack, and the interactions
| between the two undo stacks are terrible and terribly frustrating
| --yet doing without _might_ be even worse, because they behave
| very differently.
|
| And too often in a browser context, ^W will close your tab,
| losing data, rather then being inhibited and erasing the last
| word, as it should. That one is practically _unforgivable_ in a
| Vim mode, yet common. That, more than anything else, will make me
| avoid a Vim mode.
| 8f2ab37a-ed6c wrote:
| That's been my experience as well. I tried a few times to make
| my regular vim bindings + plugins to work in Rider and there's
| always that last 5% that seems to not work quite the way you'd
| expect, even for supported plugins. Bummer.
| __MatrixMan__ wrote:
| Yep, it's apparently easier to move your IDE into vim than it
| is to move vim into your IDE.
|
| The only vim mode I've met that wasn't infuriatingly incomplete
| was emacs evil mode.
| teeray wrote:
| > And they're always frustratingly incomplete and/or buggy
|
| I refer to this as the Vim Uncanny Valley
| JadeNB wrote:
| Feature request: `:vuv` causes vim to replace native
| operation by a broken, buggy half-implementation. Optional
| enhancement: LLM learns your favorite commands, and makes
| sure that they specifically are broken.
| ofalkaed wrote:
| >And they're always frustratingly incomplete and/or buggy.
|
| My favorite is all the applications which have a vim mode and
| are clearly done by people who think that just means making
| hjkl act like arrow keys and adding in a few single key
| commands. I wish more people would take the time to understand
| what modal editing actually is.
|
| In a project of mine which has an editor that is pretty much
| vim with a few modifications to suit my purposes and slimmed
| down to just the needed features, I added an optional emacs
| mode which can be enabled with C-M-e M-S-m, it enables emacs in
| evil mode.
| djtango wrote:
| One day during my vim journey I discovered filters and
| realised I could turbo charge my editing by running
| selections through any and all of unix and now I don't need
| fancy spacing plugins - I have `column` and I can `sort`
|
| This then allowed me to golf a one line vim macro that shells
| out a selection to nc which connects to a clojure socket repl
|
| I don't think many "vim modes" would allow that. The most
| earnest of vim modes is probably evil mode. Of course, only
| your true mortal enemy could ever understand you...
| dizhn wrote:
| This ctrl+w shortcut gets me all the time when using a web
| based Spice session to work on VMs and the experience is
| similar to getting wired earphones yanked out of your ear.
| There might be a way to inhibit this behavior but I never
| looked into it because I use it to close browser tabs too.
| hexomancer wrote:
| Can you give example of vim features that you miss in the
| vscode plugin? Mainly because I likely don't know about them
| and I would like to add them to my toolkit (the surround thing
| is not a vim feature, it is a plugin, although the vscode
| plugin has that too)
| skydhash wrote:
| The "buffer" model. Half the speed of using vim in a project
| for me is the ability to manipulate the layout and having
| different "windows" on the same file. One of my most common
| workflow is to split the current window and navigate to a
| different part of the same file for reference purpose (can
| quickly switch to another file with fuzzy finding too).
|
| And quick integration with external tooling. Creating an
| extension for vscode is cumbersome.
| hexomancer wrote:
| This works the same in vscode as it does in vim as far as I
| am aware. e.g. `:vs` to split the window and moving between
| windows uses the same shortcuts as it does in vim.
| nunez wrote:
| Region select. Custom keybindings. Macros.
| hexomancer wrote:
| All of those are available in the vscode plugin.
| gmassman wrote:
| It's been a long time since I used vscode (~5 years) so my
| experience may be out of date. But I recall the vim plugin
| missing the quickfix list and :cdo. Also there were quirks
| with y and p that didn't happen when using vim (maybe extra
| whitespace getting inserted).
| MantisShrimp90 wrote:
| It's night and day. Vscode was never meant for the workflow,
| so even small things like moving to the sidebars and
| interacting with them using the keyboard is a pain in the
| ass.
|
| Setting up custom hotkeys is an exercise in patience, and you
| are constantly fighting with native hotkeys that try to do
| the same thing.
|
| I tried making vim mode work for years and I always go back
| to the original because it's where I'm at home
| Lio wrote:
| > _In VS Code, it maintains its own undo stack, and the
| interactions between the two undo stacks are terrible and
| terribly frustrating_
|
| That's because Vim has a more sophisticated undo stack than VS
| Code.
|
| Vim keeps its history as a tree where you can jump between
| branches.
| chrismorgan wrote:
| It's not about stack versus tree; it's about the granularity
| of changes and what causes actions to be pushed to the undo
| stack (where there's a pretty fundamental difference between
| modal and non-modal editors), and the fact that I suppose VS
| Code just doesn't let extensions directly manipulate the undo
| stack in the way required.
|
| Look through https://github.com/VSCodeVim/Vim/issues?q=undo,
| there's a lot. VSCodeVim tries to make it behave more like
| Vim, and because it's independent of the native undo stack,
| it's frequently a _miserable_ experience. Pretty sure I
| disabled it, when I tried using VS Code for a short while and
| with Vim mode.
| drzaiusx11 wrote:
| There's a vscode extension that embeds NeoVim and just uses
| VSCode UI as a front end to delegate key presses to:
|
| https://github.com/vscode-neovim/vscode-neovim
|
| This yields a better experience than the old half baked VSCode
| vim emulation.
| faraazb wrote:
| This setup 'just' works for me. I have mapped certain
| functionality, for e.g. toggling the file explorer to a nvim
| keymap (the extension also enables h, j, k, l, y, p, etc.
| commands in the explorer) but I use the cmd/ctrl + P keymap
| for searching files in the current project, so it feels
| incomplete sometimes. When I am editing a set of files it
| works great, but as soon as I use a VS code feature, for e.g.
| project search, the experience is okay and may require a
| mouse, which is not surprising but I hope the integration
| gets even better.
|
| I am sure that with more configuration, the experience could
| be made more NeoVim like but I don't know whether I should
| spend time doing this or invest my time learning/adapting to
| a terminal based flow for the few tasks for which I am used
| to the VS Code GUI (browsing Git history, diffs for pull
| requests, git stash operations, debugging).
|
| I started with a base config (kickstart.nvim) after trying
| out LazyVim sometime back, but kept going back to VS Code for
| some of the tasks. So what I have now is not significantly
| better but I like it.
| alabhyajindal wrote:
| I used this for a few months and went back to the vim
| emulator [1]. I can't recall what but some of the things kept
| breaking in Neovim. And the frequent, near daily extension
| updates were annoying.
|
| 1. https://marketplace.visualstudio.com/items?itemName=vscode
| vi...
| Zardoz84 wrote:
| vrapper (vi mode for eclipse IDE plugin), have a similar issue.
| Usually don't have problems, but sometimes, both undo stacks
| begin to do very weird things.
|
| However, when I tried VS Code vim mode, I found far better than
| Vrapper or Kate vim mode.
| sourcepluck wrote:
| > And they're always frustratingly incomplete and/or buggy.
|
| Have you tried evil-mode (Emacs VI Layer - E.V.I.L.), an
| implementation of the vim-bindings in Emacs? I've heard it
| works very well.
|
| Or, at least, the Emacs subreddit seems to get a pretty steady
| flow of people who come from vim and get into Doom Emacs, which
| has evil-mode (and lots of other stuff) pre-configured and
| ready to go.
|
| They seem very happy, from reading their reports, anyway.
| sauercrowd wrote:
| This is my current setup, and I love it. To me it brings
| together the best of vim with the richness of Emacs.
|
| Setting up Emacs from scratch is quite the project though if
| you want all the bells and whistles
| sourcepluck wrote:
| To get all the bells and whistles done oneself, yes, it is
| time and learning.
|
| Using Emacs with no bells and whistles just for writing is
| very enjoyable too, though! That's how I started. Within an
| hour or two I'd removed any visual clutter from the screen,
| and put on some dark theme (just clicking around the menu
| bar).
|
| M-x help-with-tutorial (which came up when I first ran it,
| and I said oh, what's that), and that was me gone!
|
| For weeks and weeks all I did was pump out text files with
| no formatting, being amazed that I could jump forward and
| backwards over words, sentences, and lines. It was an
| absolute joy, with a warm feeling of clarity and clean-ness
| to it.
| hmeh wrote:
| evil on Emacs has been great for me. I've been using vim for
| 20 years (vim, visual studio, vim again, now Emacs) and
| Emacs/evil for at least 5 years or so.
|
| I've heard someone say that Emacs with Evil is a better vim
| than vim. I'm inclined to agree.
| chamomeal wrote:
| Yeah when you live in vscode vim mode you learn to completely
| avoid certain vim features
| perrygeo wrote:
| > > There's a Vim mode in every single mainstream code editor
| out there.
|
| Sadly, because of the unchecked proliferation of apps added to
| the software enterprise, this is not really true. A "modern"
| software organization probably has something like: Notion,
| Gdocs, Paper, Slack, Figma, Jira, and Github. If they have vim
| mode at all, (most don't) they require learning entirely new UI
| patterns for each app - the sheer waste is astounding. I'd love
| to be able to say "I've got a professional editing environment
| set up that's highly efficient for me to write both code and
| prose. Can I, like, use my tools and edit text?". But the
| answer is always "No - we must scatter our thoughts as far and
| wide using as many tools as possible!" The lack of a workable
| vim mode makes the problem worse.
| marxisttemp wrote:
| And then they hand-wring about silos. The level of slop at
| _software_ companies is astounding. Let's drop everything to
| make sure we're writing the backend and frontend in the same
| language, and then half-document everything over Slack,
| Confluence, README.mds, and GitHub wikis.
|
| Confluence is especially stupid to me when everything happens
| on GitHub anyway, and most companies do GitOps in one form or
| another. We can literally colocate documentation next to the
| same code files it applies to, using a nice terminal friendly
| markup language. Most programming languages these days allow
| us to write Markdown documentation _inline next to the
| declaration it applies to_. But no, let's use Atlassian's
| bespoke proprietary Enterprise Offering of a rich text
| editor. Disgusting.
|
| But hey, suits need to sell their enterprise software to
| somebody.
| SlackingOff123 wrote:
| Both the VSCode vim extension and the IdeaVIM plugin for
| Intellij support surround. There's still some plugins that I
| miss in those implementations, but both projects are gradually
| adding support for more.
| linhns wrote:
| For me, they're unusable. Many have tried to shoehorn Vim mode
| into other editors. It just doesn't fit, degrade both developer
| experience and the editor itself
| stevebmark wrote:
| Agree that Vim is a language to talk to your computer, but it's
| not necessarily efficient. Vim is famously an imperative editor:
| You have to tell Vim the sequence of steps to perform. Clicking
| your mouse on a position on the screen is declarative: You
| declare you want the cursor here. With Vim you have to
| imperatively walk the cursor to where you want to go, or god
| forbid use something like easymotion.
| dylan604 wrote:
| That's like telling some small child they are lesser because
| they can't walk because they're still learning to crawl. The
| systems that vim worked on didn't even know what a mouse was.
| eloisius wrote:
| You can, in fact, click to set the cursor position and even
| click and drag to select.
| rwiggins wrote:
| Setting aside that you can enable mouse mode in vim and use the
| mouse to your heart's desire --
|
| and setting aside the "declarative" vs "imperative"
| nomenclature debate --
|
| vim is pretty dang efficient. Typing `gg` to go to the
| beginning of a file, or `G` to go the end. Or all the other
| variety of motions. There are a lot.
|
| Also, there is not necessarily any need to move the cursor
| anywhere. For example, if I'm in the middle of writing some
| string and I've decided to change the whole thing, `<ESC>ci"`
| does that, with no cursor movement required.
| tolciho wrote:
| It is imperative in certain editors that you fumble for the
| mouse whilst in vi one can simply declare 3ff to get to the
| third f on the line. Granted, I mostly do not use certain
| editors, and accidentally compiled mouse click support out of
| the terminal--brushing the trackpad risked spamming programs
| with mouse noise, and some programs would sometimes do silly
| things with it. The mouse is fine for focusing terminals, I
| guess. (No, not vim, vi.)
| cassepipe wrote:
| set incsearch
|
| Now use / (+ n or N) + Enter to move around
|
| Done
| brewmarche wrote:
| Incremental search in vim is great, you can also cycle
| through results with CTRL-G/T while typing.
|
| This even works as a motion (e.g. d / foo, then ctrl G until
| you hit the right foo, then enter to delete until there).
| Lio wrote:
| _> With Vim you have to imperatively walk the cursor to where
| you want to go, or god forbid use something like easymotion._
|
| If you prefer to use a mouse you can do that in Vim too.
|
| It even works over SSH.
| n144q wrote:
| > With Vim you have to imperatively walk the cursor to where
| you want to go
|
| I used to use vscode with mouse. Then vscode + vim with mouse.
| Then I forced myself to actually learn how to "properly" use
| vim, including all the motions plus enabling smart line
| numbers.
|
| As a result, my right hand switches between keyboard and mouse
| much less than they used to, and I can do development work with
| my hands stay on the keyboard for minutes or longer. It made me
| more efficient, and RSI was much less of a problem.
| hashkb wrote:
| I love this take. I was a die-hard Vim/Neovim zealot... but these
| days I absolutely love the ecosystem of tools that support normal
| mode. For so long hand-cramping emacs keybindings were sort-of-
| standard-in-a-few-places.
|
| If you're not convinced vimming is the best way to interact with
| your editor, you probably haven't seen a really proficient
| vimmer.
| cassepipe wrote:
| And meanwhile in every thread or article about vim, it is very
| rare to mention remapping Caps Lock to Escape (or the other
| lesser IMHO lesser options ) even though one third of user do
| it. The other two third are deluded tool fetishists that are
| ready to suffer that their most important key is the furthest
| away from the home of row because "you get used to it" even if
| that's just an unfortunate historical accident. I would have
| not stuck to vim at all if not for this one trick and I suspect
| that's the main reason behind many dropouts
| Lio wrote:
| LOL this made me chuckle. :)
|
| I always remap caps to ctrl because ctrl-[ is an acceptable
| escape key for me as I like to use other insert mode
| shortcuts. Eg ctrl-h, ctrl-m, ctrl-k etc.
|
| I know some people map to escape/ctrl when held but that
| usually means installing something like Karabiner.
| cassepipe wrote:
| Well then you should mention it when talking about vim to
| non-vimmers as not to leave them in the dark with the
| defaults. The question is not what solution you found to
| avoid the Escape key but that you did.
|
| And even though you are probably used to your solution
| having the most important key in your program be a weird
| combo is not great imho. And you are missing out on
| bash/zsh/gdb and other command line vim modes.
| Lio wrote:
| > _And you are missing out on bash /zsh/gdb and other
| command line vim modes._
|
| I'm not at all, ctrl-[ is a terminal thing. It's
| available everywhere as are the the other ctrl shortcuts
| I mentioned.
| metaltyphoon wrote:
| > it is very rare to mention remapping Caps Lock to Escape
|
| I change mine to Ctrl. This way escape for me is Ctrl + [.
| Ctrl is too useful to be in an awkward position.
| ramses0 wrote:
| I actually usually hit my Ctrl with the base of the pinky
| (ie: pad/palm of the hand) in a lot of cases.
| temporarara wrote:
| I have mapped Caps Lock to both Ctrl and Escape
| simultaneously. If you just tap it it's Escape and if you
| hold it down it's Ctrl, and it's easy to accomplish with
| xcape.
| FpUser wrote:
| >"Wha Is Vim"
|
| Something I've never learned. Not proud of it but I do not think
| I am missing anything either. I write native software for Linux
| for living at the moment.
| cbsks wrote:
| No time like the present. Give it a try. Even if you just use
| it for editing /etc files it's much more efficient than nano.
|
| Don't be intimidated by the huge feature set. I've been using
| it practically daily for 25 years and I still only use a small
| fraction of the available commands.
| FpUser wrote:
| >"Give it a try"
|
| I have. Not my cup of tea. Small file I edit in nano /
| whatever else. Anything serious is remote editing using some
| IDE. The terminal I use also has SSH file browser where you
| can click on file and edit it locally using any editor. It
| will be saved back to where it came from.
| theonething wrote:
| > I do not think I am missing anything either
|
| How could you possibility know that unless you're familiar with
| Vim?
| FpUser wrote:
| I played with it and do not think I need it.
| Lio wrote:
| I don't think there's any reason why you _have_ to learn Vi
| /Vim. I think someone could go their whole career without that.
| That seems like a perfectly legitimate choice to me.
|
| ...but, I learned vi somewhere between less running on MSDOS
| and an embedded programming course at uni in the 90s.
|
| I've used the those shortcuts in database clients, shells and
| web browsers, etc. ever since.
|
| That's a long time and a lot of value. It's payed off so much
| that I don't really remember if it was difficult to learn; I
| just use the keyboard and get the edits I want without much
| thought.
|
| Being able to know something like that and bring it with you
| across operating systems has been useful.
|
| I'm pretty sure it will still be useful in twenty years time.
| FpUser wrote:
| >"Being able to know something like that and bring it with
| you across operating systems has been useful."
|
| I did not say it is not useful for people who use it. I
| imagine for them it gets the job done perfectly. We do not
| have to be all the same.
| Lio wrote:
| Sorry I hope it came across in my message but I totally
| agree with you.
|
| We most definitely do not need to all use the same tools
| for the job. Vive la difference.
| ggm wrote:
| Even though I wince at mis remembered muscle memory using it, I
| still wish nvi had progressed a little further. I mostly turn off
| vim features. Default cut-paste with code indent is a giant
| mismatch. It's cruder, and itself a mishmash of non-joy code, but
| I found nvi suited me well for decades on netbsd and freebsd, and
| I use it still. I do run the port on osx but somehow each upgrade
| I find myself slipped back into vim. And on debian and the like.
|
| I live in Emacs for org, and vi for code edit. Happy mix these
| last 40+ years.
|
| Sometimes it's hard to recall that ex exists, inside vi. But if
| you do any :command that's where you are. Inside a simpler editor
| landscape embedded in the visual world.
|
| Ed is a sometimes tool. Always gratifying to use it!
| cutler wrote:
| "Vell Vim's just zis guy, you know"
| syndicatedjelly wrote:
| I recently gave up on VSCode because the Vim mode is still
| substandard, missing keybindings, and constantly glitches out in
| new and fun (read: not-fun) ways. I'm just gonna use NeoVim and
| program the IDE myself, in a true moment of going super-saiyan as
| a programmer
| danielvaughn wrote:
| I've yet to get sucked into Vim, though I've given it a shot on a
| few occasions. I just feel too much muscle memory with whatever
| you call normal editing. One of these days I want to really stick
| with it because I do love the verb/action/modifier idea. I'm even
| building a similar keyboard-driven editor for building UIs. It
| has commands like "s a i" (select all images), "a t n" (add text
| element as next sibling), etc.
| teeray wrote:
| > I just feel too much muscle memory with whatever you call
| normal editing.
|
| You end up the same with Vim eventually. After almost 13 years
| of using it, I sometimes have to actually type the things I do
| to articulate what command it is. I also had a moment where
| someone said, "it's just like the 'p' command in normal mode"
| and I had to really think about what they meant--in my head I'm
| just like "put line" and it just happens.
| AdieuToLogic wrote:
| Vim is efficient, in that there is no need for one's hands to
| leave the keyboard.
|
| Vim is succinct, in that what is needed often takes less commands
| than those less frequent.
|
| Vim is pliable, in that can be made to do whatever you wish.
|
| Vim is everything, vim is nothing.
|
| Mastering vim is to find Zen made possible by an exponential
| command space.
| wycy wrote:
| Learning vim was one of the best things I did for myself at work.
| Completely changed everything about the way I work and made me so
| much faster.
| steve1977 wrote:
| Article mainly seems to talk about vi, not vim. But I guess the
| author doesn't know where vim is coming from.
| revskill wrote:
| Expecting with bad assumption means you want a war.
| smusamashah wrote:
| How do you explain "w" and "wq" to save and quit the editor with
| "verb adjective object" model?
|
| These two and "i" is all I remember about vi. Or is vi a
| different thing from vim and this model doesn't apply?
| MathMonkeyMan wrote:
| "w" and "wq" happen in command mode. "verb adjective object"
| happens in normal mode. Command mode is more like ed.
|
| vim is vi "IMproved." Just a more featureful version.
| cassepipe wrote:
| I don't understand why people keep talking about :wq when :x
| has been a thing for so long now
| philipwhiuk wrote:
| Because :wq is sufficient and I need :w and :q! anyway
| cassepipe wrote:
| set confirm
| metaltyphoon wrote:
| This is probably because :X encrypts a file so too easy to
| make that mistake?
| marliechiller wrote:
| I dont understand why people even do that when ZZ is easier
| xD
| alienchow wrote:
| Vim is this editor that a senior backend engineer told me to go
| try for a week, when I was still relatively junior. Like really
| try to remember all the shortcuts, not some half-assed attempt
| then laugh about not being able to remember <esc>:wq. If I were
| able to demonstrate fluent Vim skills at the end of the week,
| he'd gift me his TKL mechanical keyboard with a Vim keycap on the
| escape button.
|
| It's been 9 years since that challenge, and I'm still typing on
| the Filco keyboard. Good memories. Although I've since moved on
| to NeoVim for the LSPs. It's nice that I can freely edit files on
| any machine for something I picked up in a week.
| cassepipe wrote:
| Yet another article about vim that does not mention remapping
| Escape even though it's a dumb historical accident that the most
| important key is the furthest away from the home row.
| sexyman48 wrote:
| _imagine you would remove the functionality that Vim mode in
| VSCode gives you from Neovim._
|
| imagine you what?
| philipwhiuk wrote:
| I think the author is not a native-English speaker.
|
| They mean
|
| > imagine if you remove the functionality that Vim mode in
| VSCode gives you from Neovim.
| rikafurude21 wrote:
| It still doesnt make sense. If you remove vim mode from
| neovim you have... Nothing?
| eonmist wrote:
| To me there was a distinct "aha" moment when the "vim language"
| suddenly made sense. Makes me think of when kids suddenly
| discover how to read.
| kazinator wrote:
| Vim is not only an editing language, but a fast-starting editor
| with a small-ish native executable, and small run-time memory
| use.
|
| This facet is typically not ported into other editors that have a
| Vim mode.
|
| Vim runs natively inside virtual machines and containers, on
| resource-constrained embedded systems, and on remotely accessed
| machines.
|
| Another aspect is that Vim can be operated entirely using a
| terminal emulator, and so can be running on a remote host to
| which the use only has a SSH or serial connection.
| trollbridge wrote:
| Well said. I use nvim with all kinds of plugins and a custom
| init.lua, and then I use vim (or nvi) when something goes wrong
| with my init.lua, and nvim won't start, or when I want to
| quickly open a file really quickly and not wait the second or
| so it takes for my nvim setup to load.
|
| Likewise, vim lets me do local editing on any system I connect
| to as there's rarely ever a Unix left that doesn't have vim
| installed. (Back when vim was the new kid on the block, I said
| the same thing about stock ex/vi - I made sure I was
| comfortable editing in vi, and then I never felt uncomfortable
| when I had to do work on a remote system.)
|
| Another benefit with vim or nvim is how easy it is to copy
| someone else's full-featured setup: one of the programmers I
| work with is really into nvim, and he figured out an ideal
| setup for both working on Go and Python code. Then he just
| shared his setup with me. Copying someone's VSCode setup with
| plugins and all and getting it all to work would be a multi-
| hour ordeal.
| xcrunner529 wrote:
| Would you mind sharing the python setup? So many options and
| it's overwhelming for someone looking to switch from vscode.
| Zizizizz wrote:
| nvim/.config/nvim/lua/plugins
|
| - `blink.lua` (auto complete drop-down) - `dap.lua`
| (debugger) - `lsp.lua` (language server ruff and pyright
| setup)
| Zizizizz wrote:
| https://github.com/KingMichaelPark/dotfiles/tree/main/nvi
| m/.... (Forgot the link)
| lawn wrote:
| I believe you can use `nvim --clean` to ignore your config
| files.
| mysteria wrote:
| The reason I chose Vim over Emacs is simply because of the fact
| that it's available literally EVERYWHERE. I've honestly never
| seen a UNIX system which doesn't have Vi or Vim installed by
| default. Emacs is more hit and miss.
| jakupovic wrote:
| Because it's part of POSIX ...
| guerrilla wrote:
| Exactly. Well, vi anyway. It's a part of UNIX. Even more
| reason to choose it.
| topspin wrote:
| > literally EVERYWHERE
|
| Chrome and youtube also support some of the common vi/vim
| navigation keys.
| kylebenzle wrote:
| What does Vim offer over Nano?
|
| After using both I settled on Nano years ago and still don't
| see how my workflow would improve with Vim.
| syndicatedjelly wrote:
| No one is trying to convince you to use Vim over Nano. Use
| whatever makes you productive
| temporarara wrote:
| Are you being serious? Vim offers so much more advanced
| features. But if you don't have a use for those advanced
| features of Vim Nano is probably more than enough for your
| use case. I just find Vim more enjoyable to use even for
| simple tasks since the commands are already in my brain and
| I really prefer the modality.
| mu53 wrote:
| guy has a seriously simple use case
| melezhik wrote:
| Well. There is nano as well
| II2II wrote:
| In the Linux world, sure. The only reason why I've seen
| nano (rather, pico) on many non-Linux systems was because
| pine was installed, and that was only on multi-user
| systems.
| dingnuts wrote:
| You should read the article. Vim does run everywhere,
| including inside Emacs. You don't "choose vim over Emacs,"
| you choose vim, and optionally Emacs if you want to use Emacs
| in whatever context. evil-mode is a great vim; using that
| won't stop a vim user from using native C vim instead of
| emacs lisp vim when logged into a remote system
|
| (source: vim user for twenty years, Emacs ten)
| djaouen wrote:
| > but a fast-starting editor with a small-ish native
| executable, and small run-time memory use.
|
| In spite of these so-called "flaws", I still prefer Emacs!
| shreddit wrote:
| So does nano
| kazinator wrote:
| Nano has all those advantages too of being small and running
| on terminals.
|
| It's not as widely preinstalled, and has a poor editing
| language. If you can breathe with your mouth closed, you want
| something else.
| nurumaik wrote:
| Zed feels quite as fast as vim though, and has remote ssh for
| remote hosts
|
| And you don't have to suffer latency when working on machines
| with 300ms latency
|
| I still use vim when I need to quickly edit some file on some
| remote host once, but for see no reason to use it over zed in
| other cases
| keybored wrote:
| I use Emacs with Evil. But for looping macros on big files I
| use Neovim.
| gorfian_robot wrote:
| vi is fine. never seen the need to get all fancy with vim.
| dartos wrote:
| Give it time.
| h43z wrote:
| My ode to why speed even matters https://h.43z.one/vimsteps/0
| linsomniac wrote:
| I was in a PyCon presentation about the Python bytecode when I
| came up with the idea that vim editing commands are a bytecode
| for executing text manipulation.
| p0w3n3d wrote:
| vim is an operating system that allows also editing files
| alabhyajindal wrote:
| Isn't this an emacs joke? Hearing this for the first time for
| vim.
| slightwinder wrote:
| > There's a Vim mode in every single mainstream code editor out
| there.
|
| Is it really a vim-mode, or a vi-mode? I mean, most of those are
| already very limited, but does any of them actually support vim-
| specific evolutions/changes?
|
| And isn't the real question here: where does generic modal
| editing end, and when does vi(m) starts to display its specific
| personality?
| dallbee wrote:
| Cho 55
| beacon294 wrote:
| I've been using vscode in java because of the cumbersome file
| navigation in bash. Is there easy full tree navigation in vim?
|
| It may also be because the terminal view is much smaller than
| vscode's smaller navigation font so I can see much less of the
| file tree in a terminal program such as ranger.
|
| I also never really mastered windows although I did master vim
| buffers.
|
| I do use tmux.
| delta_p_delta_x wrote:
| I am too stupid for Vim. The bottleneck is my brain, not my
| typing speed.
| liontwist wrote:
| Here is some material to challenge that idea:
|
| https://danluu.com/productivity-velocity/
|
| Is also funny to phrase it in terms of bottlenecks because
| bottleneck optimization is an 80/20 approach to performance.
| People who are serious about perf don't practice it.
|
| 80/20 is good for once a month tasks. When it comes to the
| primary work I do everyday I don't want to leave 20% on the
| table.
___________________________________________________________________
(page generated 2024-12-15 23:02 UTC)