If you're struggling and have the suspicion that it might not be worth it for you in the end, sure.
For everyone else, don't be afraid to learn how to be more effective by using a more expressive feature set for editing.
I think your advice is potentially harmful. Just because you didn't end up learning this doesn't mean it's useless to other people.
It's quite possible that you're just not learning effectively enough and you're not grasping the tools correctly. There's no shame in that, but to then advise people to not learn it only because you couldn't is completely pointless.
Ultimately, it might just be pleasurable to learn to use something new and use it. You "feel" like you do things differently, but to me it's just another nerdy gadget thing.
I don't really think those are very useful, they don't save you that much time. Your editor cannot guess what kind of code you precisely want to type. Or maybe you're using a language that has too much syntax. Or maybe you're typing too much code, and that can be a bad thing too.
1. Macros can be shared with different buffers which enables you to a) do complicated transformations in a step by step manner and b) do transformations where the content of one buffer affects the content of another etc.
2. Macros can have state, typically demonstrated by having a counter. Imagine replicating your keys, but somewhere in between, a number is incremented or a word from a list is being chosen etc.
3. Extension of (2) is generative ones e.g. abo abo's `tiny` package.
4. Macros can act in arbitrary buffers. For example, If you're in `dired` or `ranger-mode` or alike, you could edit the file system the same way you were editing the code.
The common denominator of all these is the keyboard. Any GUI version would either be too complex to represent all the possible variations, or there are use cases that are not covered by GUI and those use cases -if they matter to you- would be the reasons you'd be gravitating towards keyboard based editors. For the case of notepad, the uncovered use cases are quite trivial. :)
To provide a contrived example of the sort of editor macro capabilities (I believe) somezero was referring to: Imagine you have N lines of hashrocket style Ruby hashes (`{:foo => "bar"}`) and you want to convert all of them to JSON style hashes (`{foo: "bar"}`). In Vim, you can create a macro which records the keystrokes/commands used while massaging first hash (moving :s, removing =>s, etc.) and then replay that macro over any other hashes you want to change.
I just performed a very unscientific test of the example I've provided above and it took < 10 seconds to write/record and apply the macro to 100 hashes - all without touching the mouse or thinking too hard about what I was doing. I'd be interested to know 1) if a similar operation is possible using traditional GUI editors, 2) how long it takes, 3) whether or not the same operation can be performed without touching the mouse and 4) whether or not those "operations" can be shared.
Oh and you don't need to learn that much to do it, or print some large VIM cheatsheet.
> 4) whether or not those "operations" can be shared.
Better even, those can be done in python.
To be honest I prefer using basic tools and building my own when it really is necessary, instead of using complex ones, even if they are more powerful. Sometimes you can waste time coming up with good solutions that you will only use once.
No, you seem to be simply talking out of ignorance.
Integrating Vim makes it a no-brainer for those projects where I have to use VS Code.
I do substantially all of my coding over SSH, and so do most of my friends.
Examle, a persistent tmux session with splits on a big monitor, Vim/Editor in one pane with live-UT results in another and documentation/misc details (scratch?) in another kicked off as I save.
Once kiddo's go to bed I can simply 'tmux attach' from any machine with access and be up and running.
I use IDEs and Vim, but there is clear value to working completely inside the terminal.
Coding over SSH is just so convenient. It doesn't matter whether you're using a Raspberry Pi or a DigitalOcean VM.
When you're coding in vim, you're not losing all of your IDE and just getting vim. You're losing all of your IDE and getting all of the Unix userspace. Unix is a great IDE.
I don't know what this feature is not widespread enough.
If you think lowest-common denominator stuff like Notepad equals productivity because it's easy and "discoverable", then I got nothing for you.
There's a reason why the subtitle of Drew Neil's book is "Edit Text at the Speed of Thought": https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
Because when you're reasonably proficient with Vim, you think of what to do and with a few keystrokes, you've done it without the interruption of reaching for a mouse, selecting a menu command, etc. For many edits, in the time it takes to grab a mouse, orient where the pointer is on the screen and begin the process of selecting a GUI command, etc., you'd already be done using Vim and you're off to the next thing you want to do. Anyone who's been in the flow of coding doesn't want something that interrupts that and Vim is great at keeping you there.
And because Vim uses a language, it's composable in way that VS Code, Notepad, Emacs and all of the rest of editors aren't. Once you understand how to delete a word (`dw` in Normal mode), you also know how to delete sentences, paragraphs, etc. Plugins can add their own text objects to extend the usefulness of the language.
More at "Why Vim Can't Replace Emacs/Sublime Text, etc.": https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...
Forget about vim and emacs, those were for times when people were coding over SSH. Apparently you're not a systems admin, web developer or in devops, where people have to connect to servers via SSH and edit configuration files, scripts, etc. pretty much every day.
The beauty is you can use Vim on your desktop or laptop for local editing tasks (especially gVim) and for remote editing via SSH, FTP, rsync.
Finally, I've used over a dozen different editors over the years on macOS and other platforms; I decided I wanted one editor that had enough headroom that I couldn't outgrow regardless of the task at hand.
Even though I've been using Vim for 4 or 5 years as my primary editor, I've barely scratched the surface of what it enables me to do.
I've used Sublime Text; it's not a bad editor; but compared to using Vim, it’s like being in quicksand.
Sublime Text should be more modern and useful than Vim, an editor with roots going back to the 1970's. As the article describes:
>Vi is fundamentally built on command composability. It favors small, general-purpose commands that can be combined with objects to compose larger commands. By contrast, Emacs and its philosophical descendants (including Sublime Text and Atom) use monolithic, special-purpose commands.
You can't add enough special purpose commands to something like Sublime Text and have it be useable to approach what one can do with Vi/Vim and its composability.
Finally, Vim 8.0 was released just last year (2016), so it's not like it's not being updated with new features.
Last thing from the aforementioned article:
>A new, shiny, modern editor could one-up Vim by fixing some (or hopefully all) of these issues. But before an editor can replace Vim, it needs to learn everything that 1976 has to teach — not just the lesson of Emacs, but also the lesson of vi.
I honestly don't understand why people use VIM or Emacs. I'm much more productive just with notepad.
Most editors can fold code block, use syntax highlight to make code so much more readable (if you take time to choose the right colors), highlight braces, autocomplete (even sublime text can do a weak autocomplete which is already quite handy).
To be honest, when you learn to type, using the shift, control, home and end keys should be the second thing you learn. Forget about vim and emacs, those were for times when people were coding over SSH. Use Nano if you're in a terminal. Also most of what coders do is read code, not write it.