[HN Gopher] Show HN: I built an interactive course that helps yo...
___________________________________________________________________
Show HN: I built an interactive course that helps you learn Vim
faster
Hey show HN! This course came about as a result of wanting a more
targeted way of practicing using new vim commands I wanted to pick
up, rather than just trying to use them in my regular code editing
sessions. When I would try to use new commands during code editing,
my productivity took a hit because I was trying to do two different
things at once: thinking about code vs practicing my muscle memory.
So, I made a separate environment for practicing, one that had an
interactive editor, progress tracking, and achievement goals to let
me see which areas I should work on, like speed and efficiency (#
of keystrokes). When I realized it would be useful for beginners
too, I added lessons to go along with it and this course is the
result! Let me know what you guys think about it :)
Author : Silica6149
Score : 232 points
Date : 2022-07-09 12:54 UTC (10 hours ago)
(HTM) web link (www.vimified.com)
(TXT) w3m dump (www.vimified.com)
| vogt wrote:
| Amazing. I came into programming from a bit of an unorthodox
| professional background. When I started learning web app
| development in a serious way, I got blindsided by some of the
| encounters with vim. In fact it took a long time before I even
| realized that it was vim I was interfacing with at first. wish I
| had this back then.
| gordon_freeman wrote:
| Mind sharing what professional background you came into
| programming from? I find such info always interesting.
| stevebmark wrote:
| Please just read Practical Vim if you're going to double down on
| using Vim. All of these tutorials are the minimal basics. Vim
| forces you to glue together lots of inefficient commands to
| manipulate text. I feel frustrated seeing Vim users tout how
| efficient their editor is when they haven't learned all of Vim's
| nasty bells and whistles you need to actually be efficient at
| manipulating text. (When you press colon, do you know how to edit
| the command in Vim mode? No? Read Practical Vim).
| [deleted]
| bckr wrote:
| I can't really understand whether you recommend Vim itself or
| not, because of these sentences:
|
| > Vim forces you to glue together lots of inefficient commands
| to manipulate text
|
| > Vim's nasty bells and whistles you need to actually be
| efficient at manipulating text
| stevebmark wrote:
| I'm a power Vim user. I do not recommend it for code editing.
| Learn it as a curiosity if you want. It's also handy for
| quickly editing over SSH. IDEs with multiple cursors are so
| much nicer than Vim.
| azemetre wrote:
| This is odd to hear because the general consensus online is
| that vim/vim motions makes for seamless text editing.
|
| I also feel like multiple cursors is an antipattern, you
| don't need multiple cursors in vim. You need a macro, which
| is easy to make and you can pass this to a buffer to modify
| it or apply it to certain lines or the entire file.
| bckr wrote:
| cool, that's a really useful opinion!
|
| Perhaps I'll stick with VS Code over SSH, then
| pindab0ter wrote:
| There's no reason to be snarky.
| bckr wrote:
| Wasn't being snarky.
| johncoltrane wrote:
| > Let me know what you guys think about it :)
|
| Same as the last time you posted it: learning Vim has nothing to
| do with muscle memory and doing it outside of Vim is pointless.
| Plus, the "master Vim" claim is dubious given how basic the
| lessons seem to be.
|
| :help user-manual is easy, built-in, and it goes way beyond this.
| And it's free.
| Silica6149 wrote:
| Hi, I understand where you're coming from. My introduction to
| vim was through vimtutor and it was free!
|
| I agree with your point about muscle memory. Learning !==
| muscle memory. However it does make it more comfortable to edit
| code by not having to expend energy remembering the vim command
| to do something (since you can just focus on editing code).
| Practicing new vim commands in the interactive editor has
| helped me use them faster when coding. I feel that my muscle
| memory is built faster when practicing in a targeted way.
|
| The interactive editor aims to bring the skills you develop
| while practicing in it, into your daily code editing, by making
| you practice on code snippets (for all the lessons after the
| first 2).
|
| In addition, in my opinion, vimtutor and :help are slightly
| difficult for a complete beginner to parse because they
| overwhelm with a little too much information. I tried to fix
| this by making each lesson focused on a single topic, with
| short and simple explanations.
|
| Thank you for your feedback, I appreciate it!
| johncoltrane wrote:
| > The interactive editor aims to bring the skills you develop
| while practicing in it, into your daily code editing, by
| making you practice on code snippets (for all the lessons
| after the first 2).
|
| If only Vim itself was an interactive editor.
|
| > In addition, in my opinion, vimtutor and :help are slightly
| difficult for a complete beginner to parse because they
| overwhelm with a little too much information.
|
| Except I mentioned :help user-manual, which is built-in and
| offers a very gentle, progressive, learning curve. Not
| overwhelming at all.
|
| Vimtutor only introduces the basics and :help, assuming you
| mean "the reference manual" as opposed to "the user manual",
| is not suitable for the first steps of learning at all: most
| of it is really just a reference for when you are not quite
| sure about the specifics of a command or function.
|
| > I tried to fix this by making each lesson focused on a
| single topic, with short and simple explanations.
|
| Not much more than the user manual, then, and judging by the
| lesson titles, quite less.
| mtlynch wrote:
| It's a Show HN. OP's just sharing something they've been
| working on that they find interesting. No need to dump on it
| over and over.
|
| > _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._
|
| https://news.ycombinator.com/newsguidelines.html
| Silica6149 wrote:
| I kind of get where they're coming from, but I hope all my
| messages in this thread have made it clear: If you want to
| learn vim, please try all the available _free_ resources
| before considering vimified, or any other paid option.
|
| I used vimtutor and openvim and they were great starters!
|
| It was only when I tried to find something to fix my specific
| problem that I stated in the top comment, did I build this.
| Otek wrote:
| > A good critical comment teaches us something.
|
| > learning Vim has nothing to do with muscle memory and doing
| it outside of Vim is pointles
|
| He fairly expressed his opinion of the OP's project. I don't
| agree with this opinion, but let's not be such snowflakes.
| The commentator did not insult the creator.
| mtlynch wrote:
| I don't think it's constructive feedback in that it doesn't
| give anything for OP to do except just give up.
|
| johncoltrane gave the same feedback last time, so I don't
| see how this is supposed to be helpful to OP. [0]
|
| [0] https://news.ycombinator.com/item?id=31832423
| johncoltrane wrote:
| OP is pretending falsely to help people "master Vim" via
| repetition. I'm using the same strategy to steer people
| toward better ways to learn Vim, without the lies. OP
| doesn't need help, it's the potential victims of that
| scam that do.
| protonbob wrote:
| I think "lies" is a bit of an exaggeration.
| Otek wrote:
| Again, I'm not gonna defend the opinion because I
| disagree with it, but johncoltrane can give his feedback
| as many times he wants to, and I think his feedback can
| suggest to change approach to the problem, not only to
| give up. He didn't said OP should just give up, so don't
| put words into someone else's mouth.
|
| Plus I think it's great that he's suggesting to all
| readers free alternative for learning.
| supernovae wrote:
| It's a repost. don't post it over and over :)
| JackMorgan wrote:
| > learning Vim has nothing to do with muscle memory
|
| See this definition for muscle memory from Wikipedia:
|
| "Muscle memory is a form of procedural memory that involves
| consolidating a specific motor task into memory through
| repetition, which has been used synonymously with motor
| learning. When a movement is repeated over time, the brain
| creates a long-term muscle memory for that task, eventually
| allowing it to be performed with little to no conscious effort.
| This process decreases the need for attention and creates
| maximum efficiency within the motor and memory systems. Muscle
| memory is found in many everyday activities that become
| automatic and improve with practice, such as riding bicycles,
| driving motor vehicles, playing ball sports, _typing on
| keyboards_ , entering PINs, playing musical instruments, poker,
| martial arts, and dancing."
|
| I don't see why Vim commands would be any different from typing
| on keyboards, or playing a musical instrument. They are
| tactile, and rely on motor control.
|
| > and doing it outside of Vim is pointless
|
| I see no reason at all why this should be true. Does the tool
| let the learner use keyboard to practice memorizing the
| commands, and they produce the exact same effects as inside
| Vim? If yes, then by what claim do you say it is pointless? A
| claim that this tool isn't "the real Vim" feels like a "no true
| Scotsman" fallacy.
|
| This whole comment reads like sour grapes. Are you mad that it
| isn't free? Just come out and say that. Perhaps reference
| Socrates, and how he was angry at the suggestion he charged
| money for education. Or just point out the free resources and
| leave it at that. No need to attack him so strongly.
|
| And before someone else says it, yes, I wrote a book about Vim,
| and no, it isn't free ;)
| johncoltrane wrote:
| > I don't see why Vim commands would be any different from
| typing on keyboards, or playing a musical instrument. They
| are tactile, and rely on motor control.
|
| They are not tactile and they don't rely on motor control.
| It's typing them on your keyboard that is tactile and relies
| on motor control. I make use of muscle memory to type these
| words, not to decide what to type. Learning Vim is learning
| how to decide what to type, learning how to type it or to
| type it quickly is just learning typing.
|
| The "memory system" mentioned in that quote is definitely
| involved in learning and using Vim but the other "system"
| mentioned, the "motor system" only deals with _typing_
| things. The real hero, here, would be the "language system"
| in charge of assembling commands.
|
| > I see no reason at all why this should be true.
|
| And yet it is.
|
| > Does the tool let the learner use keyboard to practice
| memorizing the commands, and they produce the exact same
| effects as inside Vim? If yes, then by what claim do you say
| it is pointless?
|
| The learner can do all that within Vim itself so why do it
| outside Vim, which is freely available and comes with an
| extensive yet very approachable tutorial that goes way beyond
| what is offered in those online knock-offs?
|
| Again, the tool in question only seems to cover very basic
| topics that are not going to help anyone "master Vim" anyway
| so why bother with it at all?
|
| And again, learning Vim, let alone "mastering" it, has
| nothing to do with muscle memory and rote learning at all.
|
| Vim itself comes with everything one needs to learn it. Learn
| Vim in Vim.
|
| > Are you mad that it isn't free? Just come out and say that.
|
| Well, I noticed that it went from $25 to $10 between posts.
| Who knows? Maybe it will be free by the third repost?
| Whatever the cost, the claims are false and there are much
| better ways to learn Vim anyway.
|
| > No need to attack him so strongly.
|
| Persons curious about Vim don't really need to be fed
| outlandish claims and promises one can't deliver either.
| immigrantheart wrote:
| I'm a vim user. Over the time I dwindle down my plugins and stick
| to the basic ones because I often do SSH and don't want my
| environment to change rapidly.
|
| One thing that I still need though, is proper syntax
| highlighting. I wish there is an easy way for vim to do it rather
| than just too many plugins here and there.
| JulianWasTaken wrote:
| Do what makes you happy, but just in case you weren't aware,
| vim supports editing over SSH natively, so there's not really a
| need to skimp just because you need to edit files remotely, you
| can use your local machine's setup to edit remote files. The
| SCP incantation is `vim
| scp://user@myserver[:port]//path/to/file.txt`, or see `:h
| netrw` or various tutorials you'll be able to find.
| immigrantheart wrote:
| Ooh I didn't know this. Thank you.
| ronyclau wrote:
| Two suggestions:
|
| 1. Prefer sftp over scp whenever it's available. The scp
| protocol is pretty obsoleted. Just substitute `scp` with
| `sftp` in the command.
|
| 2. Turn on ssh multiplexing to drastically shorten the wait
| time when opening a file.
| dash2 wrote:
| I really want to like vim and I love some things about it, like
| the ability to move chunks about with only the keyboard. But so
| many things about it kill me. Like, why can't I hit right at the
| end of a line, and move to the next line? Who thinks that is a
| good idea? Also, why do I have to have a special mode to insert
| things? Having to change modes just seems so complex and
| unintuitive. And why does the help system never tell me what I
| want?
|
| The frustration is that probably there are fixes for all these
| things, which if I were an expert I would know. But meanwhile I
| can use an ordinary visual text editor and _I don 't have to
| learn anything new_.
| snet0 wrote:
| > why can't I hit right at the end of a line, and move to the
| next line?
|
| I know this is probably something that sounds like someone too
| far down the rabbit-hole to see where they came from, but I'm
| not sure why you'd want to do that. The horizontal movement is
| probably adjacent to the vertical movement on your keyboard.
| Just use the appropriate movement to get where you want to go?
|
| > Also, why do I have to have a special mode to insert things?
|
| Because then you can use the regular keyboard, i.e. keys that
| would normally insert characters, as control inputs.
|
| > But meanwhile I can use an ordinary visual text editor and I
| don't have to learn anything new.
|
| You don't have to learn anything new because you don't want to
| _do_ anything new.
| dash2 wrote:
| My answer to all these things is that 90% of the time, I am
| not using a text editor. I will be writing in Word, or in
| LyX, or in RStudio, or in a text box. My muscle memory is
| used to that.
|
| You're absolutely right. You do sound far down the rabbit
| hole! I am used to being able to hold down the right key and
| traverse my entire document, as far as I like. Why would I
| want to stop at the end of a line? Any time I'm editing
| multiline text - like, say, English - that is essentially
| arbitrary.
|
| The regular keyboard... right... but what if there were some
| kind of special key that could be pressed to issue controls?
| Why is that worse than having a special key that goes into
| control mode? This is analogous to having caps lock, but no
| shift key.
|
| Again, you're right, I don't want to do anything new. Why
| would I? I want to get on with my job. If the response to my
| complaints is "the problem is with you, my son", without any
| idea of the ultimate benefits I might gain from changing,
| then yeah, I'll pass. Honestly, this applies not just to you,
| but to all the responses below... they're all like "if you
| try it, one day you will understand". That's probably what
| people say about Morris Dancing.
| snet0 wrote:
| > I am used to being able to hold down the right key and
| traverse my entire document, as far as I like.
|
| I mean chances are, if you're holding down a key in vim,
| you're doing an inefficient movement. That's kinda the
| point: it's a keyboard language that turns complex actions
| into compound, simple actions. If you're still using the
| simple movement and complaining about it not doing what you
| want, you're just not using vim correctly.
|
| I'm not sure why people get this defensive, though. People
| like vim, people like editors-that-aren't-vim. Is that not
| okay? If you don't want to learn to use vim, this link
| isn't for you.
|
| > but what if there were some kind of special key that
| could be pressed to issue controls?
|
| This works for a limited number of shortcuts, and when you
| only want to issue a few. The point is that you can now
| issue a large number of "command" inputs, very quickly,
| without holding down a key.
|
| > Again, you're right, I don't want to do anything new. Why
| would I? I want to get on with my job.
|
| Then uh... don't use vim? Do you post on every "I wrote xyz
| course for abc language/tool/technology" expressing that
| you don't want to use it?
| maleldil wrote:
| > I will be writing in Word, or in LyX, or in RStudio, or
| in a text box.
|
| You might still spend more time editing than writing, and
| Vim's modal approach makes editing more comfortable to me.
|
| > Why is that worse than having a special key that goes
| into control mode? This is analogous to having caps lock,
| but no shift key.
|
| The assumption is that modal editing is more comfortable
| and powerful. I can traverse the text and make
| modifications and replacements without holding chords
| between Ctrl, Alt and letter or arrow keys for long periods
| of time. Vim's model with text objects also makes some
| things easier to do than what you can accomplish with
| chords on editors liks VS Code.
|
| If you spend a significant amount of time writing in all
| caps, you might benefit from having a Caps Lock key instead
| of shift.
|
| > I don't want to do anything new. Why would I? I want to
| get on with my job.
|
| Vim is something that's radically different from other text
| editors. If you think the learning curve is not worth it,
| it's up to you. It might not be; it's not like it will turn
| you into a better writer or programmer. But its uniqueness
| was enticing enough for me to give it a go, and I realised
| I enjoyed working with it.
|
| > "if you try it, one day you will understand"
|
| I don't think you should try Vim because it will magically
| make you a better professional. That's a fantasy some
| people use to justify the time investment they made to
| adapt to Vim. I think you should learn it if you're
| curious, and it's fine if you start learning and decide
| it's not worth your time. Have you never learnt something
| just for the fun of it?
|
| PS: If you use VS Code or a JetBrains IDE, I don't
| recommend switching to Vim. Just do Vimtutor and go back to
| your regular IDE with a Vim plug-in. VS Code's is pretty
| good. This is the best of both worlds: you get all the
| powerful extensions and general IDE goodness while having
| Vim's Normal and Visual modes. As a bonus, you can still
| use the regular navigation and editing shortcuts while in
| Insert mode in VS Code. E.g. navigiating and selecting with
| Shift, Alt and Command plus arrow keys works like normal,
| so you don't need to switch modes for small things.
| yetanotherjosh wrote:
| Are you interested in learning a potentially new and more
| efficient way of doing things? Then you have to stop being
| annoyed that your habitual way of doing things is unavailable
| to you, and stop assuming your habits are the obvious and
| correct way.
|
| The modal nature of Vim is one of it's key features and makes a
| lot of sense. If you consider the keyboard the primary, if not
| singular, means of interaction, then there will be times you
| want to use the keyboard to type text and times you want to use
| the keyboard to control the editor behavior. In a "normal"
| editor, you have to use modifier keys to enter commands. In
| Vim, you do it by changing modes. It's actually quite powerful
| but you can't get past your own assumptions about efficiency.
| hasperdi wrote:
| >...more efficient way of doing things?
|
| Is that a fact, or you just parroted other people who made
| similar claim?
| greenthrow wrote:
| It is a fact. The grand parent is talking about slowly
| navigating around one character at a time. Vim has much
| more efficient ways to move the cursor to where you want to
| go.
| [deleted]
| MAGZine wrote:
| for me it is a fact.
|
| I still use the mouse from time to time when editing text
| mind you. But for most actions, I would not think of moving
| my hand to the mouse, because it is slow.
|
| Even before vim, I made gratuitous use of end of line
| navigation via keyboard (home/end buttons; cmd+arrow keys).
| vim is just a more powerful version of those buttons.
|
| I make no claim that vim is the MOST efficient platform
| ever created, but it's a lot faster than mouse+keyboard
| and/or out of the box editing methods.
| hasperdi wrote:
| I would like to leave this link to SO page on mouse vs
| keyboard... You may be faster with a keyboard, but may
| ONLY feel faster with the keyboard.
|
| https://ux.stackexchange.com/questions/30682/are-there-
| any-r...
| dimensional_dan wrote:
| > I really want to like vim
|
| > Also, why do I have to have a special mode to insert things?
|
| First and foremost Vim is a modal text editor. If you don't
| like that Vim is probably not for you. Your comment is kind of
| like saying I'm really trying to like chocolate, but I don't
| like the flavour.
|
| There's a Vim way of doing things, if you really take the time
| to learn it then the questions you are asking will all be
| resolved.
| robertlutece wrote:
| > Like, why can't I hit right at the end of a line, and move to
| the next line?
|
| :h whichwrap
| naillo wrote:
| Learning new things is fun and you get used to it. I like the
| shift A command for moving to the end of the line (and go
| directly to insert mode). A good tip is to mainly stay in edit
| mode (and remap caps to escape and hammer that to go back to
| the default non insert mode whenever you're done).
| VoodooJuJu wrote:
| >Like, why can't I hit right at the end of a line, and move to
| the next line
|
| What do you mean by this? Do you mean the right arrow key?
|
| The mode paradigm was definitely weird to me too at first, but
| it eventually makes sense, especially when you start using
| macros.
|
| I agree about the help system - it hasn't been very helpful to
| me either. I usually am better off consulting stackoverflow or
| vim's wiki for how to do something.
|
| Vim took me quite a bit of time to learn beyond the basics, but
| once I learned it, it became a productivity boon. It's nice to
| have the same powerful text editor available wherever I ssh to,
| right in the terminal, in the same place I'm using all my shell
| commands.
| bitlax wrote:
| https://gist.github.com/nifl/1178878
| mpalmer wrote:
| > _an ordinary visual text editor_
|
| Funnily enough, Vim is short for "Vi IMproved", and its
| predecessor vi is short for "visual"!
|
| ---
|
| Taking the time to learn Vim yields significant rewards if
| you're willing to meet it on its own terms. I certainly grant
| you that it's not for everyone. It's the agony and the ecstasy
| of deep tools. No pain, no gain.
|
| > _The frustration is that probably there are fixes for all
| these things, which if I were an expert I would know._
|
| I would submit that if you were an expert, you would not have
| the same list of gripes. To wit:
|
| > _Like, why can 't I hit right at the end of a line, and move
| to the next line?_
|
| This is a fair complaint, but one that's actually never
| occurred to me as a Vim user, because:
|
| > _Why do I have to have a special mode to insert things?_
|
| It's a core part of Vim's design! In fact, insert mode is The
| other mode (Normal mode) is where the _real_ power is. It 's
| not so much about moving chunks of text around with the
| keyboard as about moving the cursor.
|
| Vim divides normal mode key commands into motions and
| operators. operators add/remove/change text, and motions move
| the cursor.
|
| For instance:
|
| - `d` is an operator deletes text.
|
| - `w` is a motion that moves the cursor to the start of the
| next word
|
| - `12w` does this 12 times (practically every motion can be
| repeated like this)
|
| But the rubber really meets the road when you combine them.
|
| If you hit `d` once in normal mode, nothing happens: you've
| started a command but Vim is waiting for you to finish it by
| entering a motion. `dw` deletes from the cursor up to the start
| of the next word (you can guess what `d12w` does).
|
| > _And why does the help system never tell me what I want?_
|
| Perhaps start with `:help help` :)
| lovehashbrowns wrote:
| These sorta combinations and things like visual block mode
| are why I can't let go of vim. You can also do:
|
| set -o vi
|
| And get vim in your bash shell. Then you wonder what the
| default mode is, and it turns out it's emacs and you can do
| wild things like ctrl-A to go to the beginning of the line.
|
| And now I cringe when ever I see someone painstakingly left-
| arrow for 30 seconds to edit something at the beginning of
| their bash prompt.
| Silica6149 wrote:
| I think most people would agree with you. Being comfortable in
| your editor of choice and knowing the shortcuts in it will
| already make you faster than trying to use vim from scratch (at
| least for a while). Vim definitely needs to be practiced and
| used more frequently to get up to the same speed as regular
| editors. However, you can reach (an arguably) faster speed in
| vim.
| nomoreusernames wrote:
| press o?
| konart wrote:
| > there are fixes for all these things,
|
| No, because those are features, not bugs. If don't want them -
| you don't have to even think about them.
|
| >Like, why can't I hit right at the end of a line, and move to
| the next line? Who thinks that is a good idea?
|
| It's not that you can't. The idea behind vim-like navigation is
| that you don't press those arrows (or hjkl for that matter) in
| a consecutive manner (or hold) unless you really have to. 99%
| of the time you jump to some place in the text (a character, or
| line, a word, a nth line etc).
| agumonkey wrote:
| Have fun in other editors for a while (no need to suffer
| something that annoys you), and reconsider vim in a year. Its
| ergonomics can be frustrating at first but the design is sound
| enough to be valuable, fun even. And I say as an emacs user :)
|
| You don't really move a caret around in vim, you process units
| of text and lines.
| [deleted]
| firechickenbird wrote:
| Invalid email
| Silica6149 wrote:
| On it!
|
| Edit: hmm, can't find any errors. Can you reply with the first
| 3 letters of your email? You can also contact me via the email
| located at the bottom of the page.
| firechickenbird wrote:
| got it, need to pay before login
| [deleted]
| Linda703 wrote:
| CoffeePython wrote:
| Congrats on launching :) I built a pretty similar tool last year
| [1]. This looks like it has some nice improvements over the stuff
| I did with mine.
|
| Wish I had the time to improve on the course I launched but I
| ended up starting a company shortly after launching my course and
| getting into YC.
|
| [1] https://www.vim.so
| smitty1e wrote:
| This looks interesting.
|
| I also paid for https://vimvalley.com/ and am a satisfied
| customer.
| bordercases wrote:
| naillo wrote:
| Love it!
| Silica6149 wrote:
| Thanks! If you wanted any features that are missing, let me
| know!
| mknsri wrote:
| I tried out vim for a month or so. I did enjoy using it, although
| I'm not sure if using vim just feels more productive because you
| press more keys to do the same thing. However multi-cursor
| editing and cutting whole lines in modern editors is way more
| conducive to my workflow and eventually stopped using vim.
|
| Do vim users know if there was anything like Select next
| occurrence in vim? Feature discovery is not one of vims strong
| suites
|
| EDIT: More specifically by multi-cursor editing I mean selecting
| multiple occurrences of a word, and then editing in place. For
| example selecting all occurrences of the word user -> (getUser,
| setUserId, variable declarations with user) and then replacing
| them with account. This can be done with vim but is nowhere near
| as fast, since every change needs to be done one-by-one. Or
| selecting all the above occurrences, and pasting them somewhere
| for an interface declaration.
| tylerhou wrote:
| I use / to search by a string (or press * while my cursor is on
| a word to search for that word), then press n or p to go to the
| next or previous. cgn changes the matched text, and you use .
| to repeat the change, so to change a word over all occurrences
| I just cgn once and repeatedly press "." .
| mknsri wrote:
| Yeah this is the way I tried it. I did not find as fast.
| Morgawr wrote:
| I just select a block of code (visual mode) and use sed
| syntax, much faster than worrying about multiple cursors,
| etc and it works fine for me.
| acedTrex wrote:
| Vim has visual block mode for multi cursor which you can enter
| with ctrl-v
| mknsri wrote:
| Yeah that works for selecting contiguous blocks of text.
| Multi-cursor editing allows for selecting rows that are
| further apart.
| petepete wrote:
| vim-visual-multi works well.
|
| https://github.com/mg979/vim-visual-multi
|
| I do wish it was built in (like in vis) though
|
| https://github.com/martanne/vis
| lavela wrote:
| This article might go a bit over your head if you just started
| using vim, but I found it to be very helpful for typical
| multiline/multifile editing tasks in vim:
| https://bluz71.github.io/2019/03/11/find-replace-helpers-for...
| mknsri wrote:
| I am aware that I could extend vim with all the missing
| features, but that seems error-prone and not worth the time
| investment, since other editors have them out-of-the-box.
| lavela wrote:
| Nowadays I have almost the opposite feeling of it not being
| worth my time and being error-prone to take up with some
| editor gui when my terminal already gives me an editor that
| does everything I want from it and in exactly the way I
| want it.
|
| But I remember having your stand point when I first started
| to try to get into vim and getting to where I am now
| definitely took a lot of invested time. Wether the
| advantages of vim are worth your time you have to decide
| for yourself and it seems like you did that already.
| kixiQu wrote:
| > selecting multiple occurrences of a word, and then editing in
| place
|
| I'm sure there _is_ a way to do this More Properly, but the
| kind of thing I 'd do is:
|
| :%s/user/account/g
|
| :%s/User/Account/g
|
| If you wanted to check each one interactively, end with gc
| instead of g.
|
| Vim is the reason I'm real confident with regexes, even
| nonsense with grouping and quantifiers etc. etc., and while I
| can see people not wanting to have to acquire that power, I
| must say it's also very handy outside of text editing.
|
| > selecting all the above occurrences, and pasting them
| somewhere for an interface declaration.
|
| I don't really understand the behavior desired here, but I'll
| bet there's something similar.
| throwawayiionqz wrote:
| What about traces.vim?
|
| https://github.com/markonm/traces.vim
| ahipple wrote:
| > Do vim users know if there was anything like Select next
| occurrence in vim?
|
| As noted in a sibling, you can press * (shift+8) in normal mode
| with your cursor over a word to find the next instance of the
| word. This also updates the search pattern so you can use n and
| shift+n to navigate forward and back between matches.
|
| If you combine this with other bits of the vim "grammar" (which
| I do think encourages a kind of feature discovery, although I
| agree there's a large learning "hump" to get over to take
| advantage of it), you can use something like cgn to change the
| currently-focused search match, n to navigate to the next
| search match, and . to replay the command.
|
| So while it's not exactly the same as multi-cursor, you can
| achieve something very similar (and just as fast) with the
| following sequence: 1. In normal mode, place
| the cursor over the symbol you wish to edit 2. Press key:
| \* (read: "find the next occurrence of the current symbol and
| update the search pattern to be that string") 3. Press
| keys: cgn (read: "change the search match under the cursor")
| 4. Type the new symbol 5. Press ESC to return to normal
| mode 6. Press keys: n. (read "find the next occurrence of
| the search pattern [set in step 2] and repeat the last command
| [the edit from steps 3-5]") 7. Repeat 6 until all symbols
| are replaced
|
| Or, in raw keystrokes, I might replace all six "foo"s in a
| document with "bar" by typing the following sequence of
| characters (having placed the cursor over a "foo"):
| *cgnbar<ESC>n.n.n.n.n.
|
| It may seem complex compared to something like multi-cursor
| editing, but the nice thing here is that there are concepts
| here that are extensible beyond the scope of that specific
| edit, and can yield similar "speedy" workflows but on a much
| wider set of tasks.
|
| - c[something] is a pattern that means "change [the given
| region]", so you could construct similar commands with
| different regions (`ciw` to change inside the current word,
| `ca{` to change the current curly-bracketed region (inclusive),
| and so on)
|
| - [something]gn is a pattern that means "[do something] to the
| next search match", so you could delete it with `dgn`.
|
| - . can replay many types of commands, so if I have a more
| complex sequence of edits to apply starting at a search match,
| I could do that too (not just simply replacing the symbol).
|
| It's a very powerful paradigm.
| Xi_Bprime wrote:
| You can search & replace all occurences of a word with the
| substitute command.
|
| Type : and write `%s/user/account/g`.
|
| Although you won't get a real-time preview and will only see
| the changes after they've happened, unless you use a bunch of
| extensions(I use nvim).
| xigoi wrote:
| > Although you won't get a real-time preview and will only
| see the changes after they've happened, unless you use a
| bunch of extensions(I use nvim).
|
| In Neovim, you can just :set inccommand=nosplit (actually,
| it's the default now).
| [deleted]
| [deleted]
| afranchuk wrote:
| If I'm interpreting "cutting whole lines" correctly, in vim
| that's "dd" in normal mode. Then you can paste (put) with "p".
|
| I agree discoverability is not great; to be honest I can't
| remember how I discovered the plethora of commands I use,
| though I do have a habit of reading the help a decent amount.
| That's how I discovered "g?" (Rot13) :D
| mknsri wrote:
| Oh yeah I did use "dd" and "p". They work OK, although they
| don't allow selecting multiple lines that don't follow each
| other.
| gbin wrote:
| Just use the number of lines you want to cut like 3dd This
| is consistent for all commands.
| maleldil wrote:
| > they don't allow selecting multiple lines that don't
| follow each other.
|
| 3dd won't work. You can use registers, though:
|
| 1. "ayy for the first line 2. "Ayy for the subsequent
| lines (repeat using .) 3. "ap to paste.
|
| You can replace a/A with other letters to copy into
| multiple registers. If there are patterns (e.g. odd lines
| to A and even lines to B), you can even record a macro.
|
| I think registers are not something most Vim users use,
| however. I have no data to back this up, but I wouldn't
| be surprised if Vim is like Git, where people learn the
| commands for 80% of scenarios and Google the rest. In
| Vim, case, they might even settle for a very inefficient
| solution if the problem is not recurring.
| wruza wrote:
| What's the use case for this disjoint selection?
| ziroshima wrote:
| Yep. I use the VIM extension for Vs Code. I do a CMD-SHIFT-P ->
| Disable Vim whenever I need this functionality. Not sure if
| there's a better way to do it.
| redhal wrote:
| No need to disable it, the feature is mapped (by default) to
| 'gb' (in the extension not in vim)
| stcg wrote:
| > Do vim users know if there was anything like Select next
| occurrence in vim?
|
| You can press '*' in normal mode to search for the word under
| the cursor.
| sy7ar wrote:
| IMO one of the best ways to learn vim after the basic movement is
| to copy others vimrc and build your own using vim. Use :help or
| :h along the way. vimrc is fairly simple to edit compare to
| actual programming languages.
| timwaagh wrote:
| I often use vim for editing files but not code. The need to
| adhere to corporate style pretty much kills it for that.
| petepete wrote:
| Is editorconfig any use there? It definitely makes life easier
| on projects where the contributors have a mix of tools.
|
| https://editorconfig.org/
| Arisaka1 wrote:
| I once tried to migrate from VS Code to Neovim. I use TypeScript
| at work, and use many languages for my side projects.
|
| But the worst part was making Vim provide with things that you'd
| expect programming editors to have. So many options, what's best
| is up to opinion, integrating language servers, getting
| intellisense to work as you would expect, searching the project
| folder for file names.
|
| Then I realized that all I'm trying to do is make Neovim behave
| like VS Code with the extra addition of keyboard navigation,
| which I can get behind. But at my current career level I'd rather
| spent those 5-10 hours configuring an editor in learning more
| about <insert whatever language/framework I'm learning>.
|
| I mean, just another Vim introduction when you already have the
| free options (vimtutor etc.) and FEM's "Vim Fundamentals" won't
| fix my pains with getting it to work as I'm expecting it to work.
| cercatrova wrote:
| You might like prepared Vim frameworks then, like SpaceVim
| which was recently on HN [0].
|
| [0] https://news.ycombinator.com/item?id=31986851
| user3939382 wrote:
| I tried hard to convert from my IDE to vim. I write PHP and
| rely heavily on for example EA inspections, there is no way to
| get these in vim. You can do some analysis with either psalm or
| phpstan, I forget, but in any case that was a show stopper for
| me.
| stevebmark wrote:
| Vim is a text editor, not a code editor. IDEs are much more
| efficient for code edit.
| the_gipsy wrote:
| Vim is a code editor, IDEs are mouse-navigators.
| olalonde wrote:
| That's wrong. Vim can be setup as an IDE and it's the IDE of
| choice for many developers.
| pgrepds wrote:
| I tried the same a couple of month ago and I came to the
| conclusion that VIM will never come close to editors like VS
| Code.
| eckesicle wrote:
| Okay, but you spend 2000 hours per year at work.
|
| So 10 hours on a config is only .5%, which is the productivity
| gain you need to realise to get that time back in one year
| (assuming you also spend 0 hours on fighting vscode).
|
| Unless you're retiring within the year, that calculus doesn't
| make sense.
|
| The productivity boost you get with from Emacs/vim is huge once
| you learn it well.
|
| I strongly believe that learning one of these two editors is
| probably the easiest and biggest skills leap you can take as an
| intermediate or senior developer.
|
| No other skill you can learn will have as big of a payoff to
| your productivity given the relatively small effort to get
| proficient.
| mypalmike wrote:
| I've been coding for nearly 40 years and I just don't see any
| correlation between editor usage and developer productivity.
| Being able to design and work with complex software systems
| is what makes a senior dev productive, not which keys they
| hit to copy and paste.
| what-the-grump wrote:
| I really doubt that the tools of your trade do not matter.
|
| I've been building corp infrastructure for a decade and I
| can tell you first hand how much of an impact fast, stable,
| updated environment can have on organizational productivity
| and overall output. I doubt devs are some how excluded from
| the pack.
|
| The old proverb of shit in shit out also applies.
| mypalmike wrote:
| You have a fair point about tools and environments. I
| just don't think of editors as being a significant part
| of an environment, nor a significant differentiator of
| tooling.
|
| I've worked on teams where some members used IDEs and
| others used traditional text editors, and what
| differentiated their productivity was inevitably between
| their ears.
| azemetre wrote:
| You should see how slow people are at doing the following:
| creating a new directory, creating several files,
| initializing git, and creating a new work tree.
|
| While learning vim/emacs and CLTs may not make you a better
| programmer, but they can absolutely make you better at
| understanding and using your tools effectively.
|
| One simple thing I like to do at every job is setup an
| ansible playbook for the team I'm working on. What ansible
| allows is me to setup a tool to download all the relevant
| languages, binaries, create company specific repos for
| directories, establish a foundation of common CLTs,
| automatically install software, and fully setup all the
| paths. Now any person, old or future hires, can literally
| set up their machine in less than 10 minutes; an activity I
| see people usually give a full "week" to do.
|
| This is just one example of being more productive with
| these tools. What's nice about vim are vim motions, they
| become extremely intuitive and all the supporting
| libraries, plugins, and other CLTs utilize these vim
| motions which makes productivity extremely nice.
|
| If you want to see someone's workflow I'd checkout
| ThePrimeagen's video on his workflow:
|
| https://www.youtube.com/watch?v=bdumjiHabhQ
| mypalmike wrote:
| Command line tools are great. Environment setup is great.
| Ansible is great.
|
| I don't know why you are conflating these things with the
| editor one uses.
|
| *Edit: Why the downvote? Tell me what I'm missing
| instead.
| azemetre wrote:
| I didn't downvote.
|
| Most of these tools I tie in with vim hotkeys to shoot
| off various things. For example, I use telescope to jump
| between different git worktrees using vim motions or when
| using tmux I have vim motions mapped to maneuvering
| around panes (tmux cmd + hjkl) or going back to previous
| window (tmux cmd + o).
|
| I'm not saying you can't learn to use these tools without
| vim/emacs but in my limited work experience those
| developers that use vscode for everything tend to be
| completely lost when the terminal takes the fullscreen.
| psydvl wrote:
| What about prepared set of plugins for vim for typescript
| https://spacevim.org/use-vim-as-a-typescript-ide/
| eric-hu wrote:
| I use VSCode with NeoVim as a backend.
|
| https://github.com/vscode-neovim/vscode-neovim
|
| I highly recommend this if you know vim keybindings and want an
| IDE experience.
| bashinator wrote:
| Beautiful - I've been waiting for something like this since
| neovim was announced with enbeddability as a design goal.
| [deleted]
| Otek wrote:
| This is a good starting point if you ever feel like trying
| again with Neovim.
|
| https://github.com/nvim-lua/kickstart.nvim/blob/master/init....
| cutler wrote:
| LunarVim may be what you're looking for.
| faizshah wrote:
| I got further with spacemacs, it has a lot of stuff that's
| sorta batteries included but you can still use vim bindings. I
| still just use ideavim in pycharm and webstorm but I have been
| slowly exploring some things like magit and org in spacemacs.
| immrammc wrote:
| If you're trying to achieve VS Code with the keyboard
| navigation of vim, have you given the VSCode vim plugin a try?
| I've had positive experiences mixing editors/IDEs with a vim
| plugin to get the best of both for my workflow.
| jrasm91 wrote:
| This. VSCode has so many great features. Adding in
| keybindings for vim via a plugin has worked great for me.
| MAGZine wrote:
| I use this but my god the VS Code vim plugin pisses me off
| sometimes. It's good probably 99% of the time. But I feel
| that (from time to time) it collapses multiple commands into
| a single undo action.
|
| Frequently I find myself frustrated that I can't undo exactly
| what I need to, and it ends up undoing more than I want it
| to. I never had this problem with vim but with vscode, I
| probably experience it once a day.
| chadcmulligan wrote:
| Nicely done. Though I have to say - I gave courses on vi in the
| 80's but then IDE's and GUI's came along and I moved on. I will
| never understand why anyone still uses vi in the 21st century,
| except for occasionally editing a config file on a *nix box.
| bityard wrote:
| Oh man, you are going to get a ton of replies on this.
|
| Short version: vim is not vi.
|
| Longer version: I use vim because I am way faster with it than
| any standard editor. I personally barely customize my vim at
| all, but there is a large community whose hobby is installing
| dozens of plugins to turn it into a full IDE and/or making it a
| highly personalized experience.
| ilrwbwrkhv wrote:
| Neovim is pushing the text editor space like nothing else.
| mastermedo wrote:
| I love projects that popularize vim. But I think this one might
| be in a way too early stage to justify the pricing (assuming
| those 8 lessons are all there is).
| Silica6149 wrote:
| Thanks for the feedback! The 8 lessons you mention are actually
| 8 chapters.
|
| There are actually 34 lessons right now (you can see the
| lessons if you click on the chapters to expand them).
|
| Please let me know if there are topics that you want to see, I
| wanna add what people want to learn!
| phkahler wrote:
| Just type "vimtutor". If you have vim you should also have
| vimtutor.
| quest88 wrote:
| How does yours compare to shortcutfoo.com?
| Silica6149 wrote:
| Thanks for asking, I actually have practiced vim on
| shortcutfoo.
|
| It is really good for remembering shortcuts for regular desktop
| applications, but I felt that it wasn't really meant for
| learning a code editor like vim.
|
| It did not have an interactive code editor, with the ability to
| edit lines of code inside of it. In addition, it does not
| measure progress in terms of speed and # of keystrokes, so you
| aren't able to see how you could improve. If I recall
| correctly, it is just meant for remembering the command
| keystrokes and typing them out (kind of like using flashcards).
|
| Also, as of right now, shortcutfoo is $8 monthly, but it allows
| access to all shortcut courses.
|
| Please correct me if I'm wrong, I used shortcutfoo a few years
| ago.
| ezfe wrote:
| Tried to register using my `.dev` email address: "Invalid email"
| Silica6149 wrote:
| Hey, sorry the landing page is a little unclear.
|
| You gain access with the email you use to purchase (the buy
| button is all the way at the bottom, which I could with
| improving its location). Thanks for letting me know!
| ezfe wrote:
| Ah, that is not clear. It should say "account not found" at
| least instead of "invalid email."
| QuiiBz wrote:
| I wonder why the headline and other gradient title are images.
| Why not a text with linear-gradient and background-clip?
| Silica6149 wrote:
| Thanks for asking, I initially had them like you suggested but
| with the way I was doing it, it made it kind of hard to make
| responsive. For the hero especially, the words didn't line up
| without lots of adjusting.
|
| I'm not really good at css though, so there's that.
| imperistan wrote:
| I write C# three days a week. Is learning vim worth it?
| pluijzer wrote:
| Yes I would say. Most IDE's support vim keybindings via
| plugins. Vim kingbindings with the convenience of and IDE
| results in an powerful experience.
| Silica6149 wrote:
| Nope. If you're already comfortable in your code editor of
| choice and like it, there's no good reason to switch.
|
| However, if you've seen people use it in real life or in
| youtube videos, and think that it's cool being able to execute
| precise and fast commands without needing to move your hands
| from the keyboard, to edit code exactly how you want to,
| definitely try it!
| olalonde wrote:
| If you plan to code for many years, it's definitely worth it.
| But it has a steep learning curve. It could take you a few
| weeks before you feel like Vim is not actually slowing you
| down. But past that point, you will continuously gain
| productivity and will eventually refuse to use anything else.
| I've been using Vim for almost a decade and I'm still learning
| new tricks that boost my productivity.
| seanp2k2 wrote:
| :set nu / whatever you want to find [return] i
| *edit stuff and use arrow keys for nav* :wq Or :q to
| quit without saving
|
| That's all the vim most people need.
|
| The fact that less is installed on many more systems than nano is
| a testament to the bad assumptions too many devs make about who
| will be using these systems in the future. And yes, it's not hard
| to "apt -y install nano" except at work where we have proxies and
| internal repos, so now I need to use vim to reconfigure apt
| sources just so I can use a more normal editor that doesn't
| require arcane incantations to perform basic config file editing.
| password4321 wrote:
| My problem is I can't use the up/down arrows for nav while
| editing stuff, it just starts spewing control characters on new
| lines IIRC.
| mikojan wrote:
| Absolutely haram
| cheeko1234 wrote:
| Nano and commandline is good enough. If apt is available, Micro
| is even better.
| drodil wrote:
| When I was learning vim, I decided to extend the existing
| vimtutor with some more programming specific tasks. You can find
| it at https://github.com/drodil/codetutor.vim if you are
| interested :)
| sneak wrote:
| *interactive paid course. That should be disclosed above the
| fold, methinks.
| Silica6149 wrote:
| Definitely try out the free resources for learning vim before
| ever considering Vimified, or any paid option!
|
| I used vimtutor and openvim to get started, and they're
| fantastic free resources.
|
| It was only when I couldn't find something to fix my specific
| problem that I stated in the top comment, did I start building
| this.
| nmz wrote:
| This is the wrong way to go, if the UI is so bad it requires a
| course, then the problem is clearly the tool.
| Silica6149 wrote:
| It can also be a boon. One of the things some vim users like is
| always being able to discover something new, after using it for
| years.
|
| I'm not really in this camp though, I would prefer vim commands
| to somehow be more "discoverable".
|
| Much easier said than done, though.
| wruza wrote:
| What were the last three things that you discovered in your
| editor?
| blep_ wrote:
| In Helix:
|
| - space, k for documentation on the thing under the cursor
|
| - space, [yp] for copying/pasting to the system clipboard
|
| - m, [ai], [acfo] for selecting around/in language
| structures
|
| This is easy because Helix has a very fast command palette
| thing, and a lot of its commands are behind consistent
| prefixes, so if you know `mi(` for selecting within
| parentheses, you can do `mi` to ask "what other things can
| I select within?"
| Otek wrote:
| Which code editor does NOT have an online course on how to use
| it? Go ahead, type "IntelliJ course" or "VS Code tutorial" and
| see hundreds different videos.
| _qua wrote:
| This is a wild take. I'm not quite sure how you would go about
| changing it into something "better" without funadmentally
| destroying its functionality. The "UI" of driving a car or a
| jet requires "a course" but it doesn't meant that they're bad.
| Boltgolt wrote:
| What a strange comparison. Driving an (automatic) car can be
| learned through trail and error in no time at all. It's the
| external factors like other traffic that are hard to get
| right.
| dimensional_dan wrote:
| You're just assuming that one set of optimisations are the most
| important for everyone in UI design. Good UI design doesn't
| state that it is always the case that people should be able to
| use it intuitively. Sometimes enhanced performance, speed, and
| focus over the long term are optimised over intuitiveness. This
| is the case for Vim. There is room in the world for both sets
| of optimisations.
| stackbutterflow wrote:
| Good UI is not always optimizing for beginners.
|
| If you're using a tool for 8 hours a day, everyday, for years,
| you won't be a beginner for very long.
|
| The program must be optimized for the people who are going to
| use it for thousands of hours. Not for the users who are heard
| about vim yesterday.
| hasperdi wrote:
| Hard to learn doesn't mean good.
| JulianWasTaken wrote:
| I think this is the wrong way to think about computing, though
| I sympathize, because I also used to think this way until I
| reflected on a podcast I'd heard about how when the computer
| mouse was invented, it's little known that a second very sci-
| fy-y device was also intended to be used as a peripheral, one
| which you put on your other hand like a glove and moved in all
| sorts of ways in order to direct your computer. Ultimately this
| device didn't catch on, but it's not necessarily the case that
| just because something isn't trivial to start using that it's
| bad -- on the contrary, both kinds of tools are useful.
|
| Tools which are eminently transparent in how you use them are
| great to get started, and to continue with if you don't want to
| spend any more time.
|
| But so are tools which you need to actively invest effort into
| using. These can unlock ways of using something which are more
| powerful and rely on the time you put in to learn them -- true
| for a computer, but there are plenty of other devices in the
| world where this is the case too.
| caseymarquis wrote:
| I take it you're not a musician?
| chongli wrote:
| Or a pilot. Or an artist. Or a mathematician. Or basically
| anything difficult.
|
| This is the price we pay for having easy-to-use computers.
| People have developed an expectation that everything should
| be easy and if it's not easy for beginners then it's bad.
|
| Some things are just hard! That doesn't make them bad. Some
| of the best things in life actually take years of study to
| learn.
| olalonde wrote:
| How do you reconcile that with Vim's massive popularity?
| Surely, Vim users are aware that there are many "easy to learn"
| editors.
| MatthiasPortzel wrote:
| My pet peeve is Vim tutorials that start with "use hjkl to move
| around" instead of "use `set mouse=a` to turn on the mouse." In
| my opinion you need to make sure that you are very clearly
| disclaiming that you are teaching a harder way of doing things in
| exchange for incredibly small productivity gains that will be
| realized years in the future, if ever.
|
| (This is basically a copy-paste of previous comments I've made, I
| haven't tried your tutorial beyond the first lesson.)
| vscode-plz-stop wrote:
| I just created this account to say that I agree wholeheartedly
| 100%. People always ask me, "How do I get better at Vim?" or
| say "Vim is too hard" etc, and I always say `set mouse=a` isn't
| just a gimmick, it's a _very_ useful feature...
| Silica6149 wrote:
| Definitely a hurdle to overcome for beginners.
|
| Although, it would help to show beginners exactly why
| abandoning the mouse will be better in the long run. It
| wouldn't do well for them to always rely on it in place of
| more efficient commands. Some people might always use the
| arrow keys instead of hjkl, for example, when hjkl will be
| better in the long run since they are on the home row.
| CJefferson wrote:
| I buy the idea that the more advanced features of vim are
| worth it, being able to quickly cut+paste bits of text
| around, skip to end of line/bracket/etc.
|
| I don't believe I'd write usefully larger amounts of code
| by using hjkl instead of arrow keys, and personally I am
| always going to use the mouse when I want to move more than
| a couple of lines.
| Silica6149 wrote:
| Yup. I had tried to use vim and quit because I thought it
| was needlessly cumbersome.
|
| What changed my opinion was watching videos of people
| using vim on youtube that made me interested in learning
| it for real. It made me realize how much more efficient
| it could be.
| em500 wrote:
| I use vi(m) more often on remote servers than locally, and in
| many cases I don't have much control what software is
| available. Mouse support is a crapshoot, so I never bothered
| with that.
| Silica6149 wrote:
| Ah, I see. I agree, more context would be better for the
| beginner to understand why the lessons are the way they are.
|
| I tried to explain the benefits of vim in the "Why Vim?"
| section, but I should really go into why using and learning vim
| will be slower at first than using the editor you're already
| comfortable with, and how it might be worth it in the end.
|
| Thanks for the feedback!
| stevenjgarner wrote:
| IMO, the choice of nix editor is always somewhat contextual
| depending on how much full stack work is being done. If one
| is doing a lot of systems work (ie a lot of bash commands),
| then one inevitably wants to set a default editor on the
| systems being used. While I choose vi, it really depends on
| the number and type of systems being regularly accessed, and
| your personal preferences. For me the use of a terminal
| editor is just part of the seamless flow of using the command
| line for everything else. I personally don't think it is
| especially valuable to consider terminal editors in isolation
| away from bash, other than to become familiar with key
| strokes.
| yetanotherjosh wrote:
| a harder way of doing things _initially_ in exchange for
| incredibly small productivity gains that _when applied millions
| of times over the course of a programming career, make a
| monumental difference_
|
| A key ethos of Vim is that once you climb the initial learning
| curve, you're on a path of increased efficiency for the long
| haul. Moving the hand to the mouse, dragging the cursor to the
| spot you want, then moving the hand back to the keyboard, is
| objectively slower than key-based movement commands for someone
| who has climbed the learning curve and I'm confident that could
| be proven empirically though I'm not aware of any such proof.
| There may be certain exceptional cases where the mouse is
| faster, but for most editor usage it would not be. I'm not sure
| if you agree w/ that and are just criticizing how _tutorials_
| introduce people to Vim, that they should start w / the mouse
| to lower the learning curve, which might be an okay argument.
| delusional wrote:
| This may be a little elitist, but if you're not going to use
| vim the way it's really made to be used, why even bother? I get
| that `mouse=a` makes it more familiar, but if you're always
| going to reach for your mouse, you're never going to really get
| used to the motions.
| effakcuL wrote:
| Tbh, one of the biggest issues with vim for me is, that all
| my coworkers do not use it. When I have to explain something
| to them, they are completely oblivious as to how they
| navigate vim without the mouse. So enabling mouse is one of
| the most important things for me
| MatthiasPortzel wrote:
| I use Vim as a secondary editor, when I need to quickly edit
| a file in my terminal or over an SSH session. I'm not
| interested in it replacing my primary IDE.
|
| If you're going to disable the mouse and the arrow keys and
| really commit to the home row, more power to you. That is
| probably the best way to master Vim. But I think a
| significant number of people looking at Vim tutorials have
| never used the editor, and I think they deserve to know that
| there is an easy way to make the editor more comfortable and
| more familiar.
|
| Someone down-thread used a metaphor to say 'the best way to
| learn a new language is by immersion' which is something I
| would agree with. But opening Vim for the first time feels
| like being dropped into a foreign country where no one speaks
| your language. Imagine how frustrated you would be to find
| that the people there actually do speak a language that you
| know, they're just refusing to understand you because you
| haven't issued the magic words, "set mouse=a"
| Silica6149 wrote:
| I think they were speaking from a total beginner's
| perspective, and how to get them up to speed as fast as
| possible.
|
| I felt the same way when first learning vim, since it was
| completely different from the code editors I'd used in the
| past, it was strange not being able to use the mouse in the
| way I was used to.
| delusional wrote:
| I get that, but that strangeness is what pushes you to
| learn. I find that if I can do something suboptimal, but
| familiar, it takes way longer for me to change my habits
| because my subconscious keeps thinking in terms of the
| familiar.
|
| I find it much more useful to remove the ability to even do
| the wrong thing, than to simply try and will myself to do
| the right one.
| chongli wrote:
| _I get that, but that strangeness is what pushes you to
| learn._
|
| Yes, exactly. This is analogous to travelling to another
| country and hoping to learn the local language by
| immersion. If you then meet people that speak your
| language you run the risk of only hanging out with your
| little expat group and never immersing yourself in the
| local culture. You can end up spending years there and
| never learning the language.
| Silica6149 wrote:
| Oh yes, when I was trying to fully learn vim, I had the
| mentality that I could just practice it for 10 minutes a
| day and be able to use it while editing code.
|
| The remaining time I would edit code like normal with
| vscode, so it turned out that I wasn't really able to
| pick up vim and use it well.
|
| It wasn't until I switched to a different keyboard layout
| that I decided to move over to vim cold turkey, and was
| actually able to learn vim and retain it.
| superdisk wrote:
| I agree. When I started at my first internship, one of
| the developers (and now a close friend) put layers of
| tape over the arrow keys so I couldn't use them. Took a
| week of pain and then I never went back.
| manx wrote:
| Vim was designed on qwerty keyboards. On other layouts (e.g.
| neo2) hjkl are not in a row.
| spc476 wrote:
| Specifically, it was designed on the ADM3A keyboard, which
| had the arrows printed on the H, J, K and L keys. Also of
| note is the key in the upper right, which is labeled with
| "HOME", ~ and ^ (which explains why shells use "~/" to
| represent the users home directory).
|
| And while I'm diving into history here, vi (which stands
| for "visual") was a modification of "ex" to use the
| newfangled "video terminal" instead of the battle tested
| teletype machine.
| danielvaughn wrote:
| That's somewhat comforting to know. I'm in the beginning
| stages of building out a keyboard-heavy application, and I
| keep wondering about how to support different keyboard
| types. I suppose it's not possible to satisfy all customers
| if even Vim can't do it.
| maleldil wrote:
| Just support QWERTY but allow the user to remap
| everything. Even among programmers, the share of people
| that use alt layouts is so small that is not worth your
| time.
| BirAdam wrote:
| I very whole heartedly disagree. I find vim to be an unusable
| vi implementation until I turn off mouse support completely.
| For that matter, I also have to turn off any automatic
| indentation and any other "smart" feature that people try to
| ram into their distro-default configurations. It's nearly as
| annoying as autocorrect is on a desktop computer.
| manx wrote:
| Agreed. Hjkl only makes sense when using a keyboard layout
| where these 4 keys are located in a row. This fact made most
| vim tutorials useless for me, as I'm using the neo2 keyboard
| layout, where arrow keys are located in the middle of the
| keyboard and hjkl are not in a row. Using vim works well for
| me, and I can use hjkl for other keybindings.
| kjeetgill wrote:
| Huh. I mainly find myself disabling mouse=a if it's on by
| default. But that's mostly because the only time I'm using my
| mouse is to copy/paste something out of my term and it breaks
| that.
|
| Also, I think scaring people away from arrow keys is premature.
| It's not that big a deal.
| renewiltord wrote:
| Interesting, I always move down by page. I find the mouse to
| keyboard switching disorienting. But I know lots of great
| engineers who use the mouse extensively. I wonder if I just
| trained myself into this efficiency (and out of that
| efficiency) when I was young.
|
| I bet I could untrain with sufficient work but it's no longer
| worth it.
| [deleted]
___________________________________________________________________
(page generated 2022-07-09 23:01 UTC)