Vim as Language(benmccormick.org)
benmccormick.org
Vim as Language
http://benmccormick.org/2014/07/02/learning-vim-in-2014-vim-as-language/
7 コメント
This is what I was looking for a long time! Thank you.
As vim is not learnable in a week-end. Understanding the basics progressively (like you do with a language) seems a nice approach.
This StackOverflow answer, in the same spirit of the article, has opened eyes to many people.
"Your problem with Vim is that you don't grok vi."
http://stackoverflow.com/questions/1218390/what-is-your-most...
"Your problem with Vim is that you don't grok vi."
http://stackoverflow.com/questions/1218390/what-is-your-most...
Yep, that post is one of the things that pointed me down the road to the mindset in this article, and I mentioned it at the bottom. I still don't use everything in that post though. The depth of Vi by itself is crazy.
Although it may not stick in a weekend, the vimtutor program (if you're on Linux you probably have it installed) covers this sort of stuff.
For moving beyond the basics I suggest this book: http://pragprog.com/book/dnvim/practical-vim
For moving beyond the basics I suggest this book: http://pragprog.com/book/dnvim/practical-vim
Thanks for the book I'll take a look on it, it seems interesting.
For vimtutor it's introduced in the first part http://benmccormick.org/2014/06/30/learning-vim-in-2014-the-...
The most disturbing thing when learning vim is the fact that shortcuts actually "means" something rather than being near your fingers. Like the old flashioned way to use shortcuts in RTS games vs grid modes.
For vimtutor it's introduced in the first part http://benmccormick.org/2014/06/30/learning-vim-in-2014-the-...
The most disturbing thing when learning vim is the fact that shortcuts actually "means" something rather than being near your fingers. Like the old flashioned way to use shortcuts in RTS games vs grid modes.
Yep, thats the advantage of Vim's philosophy as a whole. You don't have to learn it all at once, and what you do learn gains power as you move forward.
I'm sort of embarrassed that I've been using Linux for years, consider myself "at home" on the terminal, use vi/vim daily, yet, know so little about it.
Use what you need. At some point, understanding the general philosophy, you'll come across a task that makes you go, "This should be easier." Google for a better way to do it and you'll probably find one.
I've been using vi for (egad!) over 30 years, and vim for about 8 years, and I still learn something new about it every now and then. In this case, text objects. I'd never run across that feature before.
An example of vi/vim's power I've used for ages is formatting a paragraph of text: {!}fmt<cr>
With text objects, in the middle of a paragraph somewhere,!pfmt<cr> -- Much easier to type!
(yes, I know vim has the gq command, but I prefer piping text to the *nix fmt command.)
An example of vi/vim's power I've used for ages is formatting a paragraph of text: {!}fmt<cr>
With text objects, in the middle of a paragraph somewhere,!pfmt<cr> -- Much easier to type!
(yes, I know vim has the gq command, but I prefer piping text to the *nix fmt command.)
[deleted]
I read a similar article a couple months ago: http://ismail.badawi.io/blog/2014/04/23/the-compositional-na...
Emacs, "a great operating system, lacking only a decent editor"[1]
Vim, "a great editor, utterly lacking a decent window manager"
The latter is just outright painful -- tabs, windows, and buffers, so much promise, yet...such fail O_o
[1] http://en.wikipedia.org/wiki/Editor_war
Vim, "a great editor, utterly lacking a decent window manager"
The latter is just outright painful -- tabs, windows, and buffers, so much promise, yet...such fail O_o
[1] http://en.wikipedia.org/wiki/Editor_war
I totally disagree with you. I find Vim's implementation of buffers/windows/tabs to be far more powerful than any other editor I've used. The ability to quickly switch between files, move a file between different windows, create and destroy splits, etc. is just so nice. Every other editor seems clunky and inefficient, forcing you to use the mouse for all of those operations.
> The ability to quickly switch between files
by context switching to the grey matter to inquire what the name of the file is and then tab complete your way to said file vs. where you visually "know" the file to be in standard panels (splits) with tabs (buffers) based editors.
> move a file between different windows
please don't lie to the uninformed -- one can only rotate windows within the same row or column, not across columns and rows -- it's rather limited.
> create and destroy splits, etc. is just so nice
I'd take drag and drop splits any day over Vim's adhoc implementation. If you create a split it's best to destroy it as it will never behave predictably; i.e. your split layout may completely collapse when closing a buffer.
and then cloned splits, man do I love to see the exact same file displayed across splits, nothing says maximize screen real estate usage like cloned content. Sure, can close the cloned split, but why waste one's time on an event that isn't even possible in GUI editors? (i.e. attempting to open an already open file brings you to its location, not pointlessly duplicates it).
> Every other editor seems clunky and inefficient
Feel the same way about Vim's window management, try Sublime, heck even try Eclipse, you get multiple visible tabs (buffers) per panel (split), and as an added bonus, the labels are set above the code (where top-down, left-right humans expect it), not below. You can also quickly hotkey rotate through all opened files, bing, bing, bang vs. either reading through a buffer list that has nothing to do with its location in visual space, or praying that ctrl-O doesn't start opening files from a previous session, or just saying ctrl-6 (toggling between 2 measly files) is the answer.
I think the deal with Vim is that you have to keep a lot in mind, literally, as in the entire set of file names you're working with, vs. visual editors where code location is representation (i.e. its "name").
by context switching to the grey matter to inquire what the name of the file is and then tab complete your way to said file vs. where you visually "know" the file to be in standard panels (splits) with tabs (buffers) based editors.
> move a file between different windows
please don't lie to the uninformed -- one can only rotate windows within the same row or column, not across columns and rows -- it's rather limited.
> create and destroy splits, etc. is just so nice
I'd take drag and drop splits any day over Vim's adhoc implementation. If you create a split it's best to destroy it as it will never behave predictably; i.e. your split layout may completely collapse when closing a buffer.
and then cloned splits, man do I love to see the exact same file displayed across splits, nothing says maximize screen real estate usage like cloned content. Sure, can close the cloned split, but why waste one's time on an event that isn't even possible in GUI editors? (i.e. attempting to open an already open file brings you to its location, not pointlessly duplicates it).
> Every other editor seems clunky and inefficient
Feel the same way about Vim's window management, try Sublime, heck even try Eclipse, you get multiple visible tabs (buffers) per panel (split), and as an added bonus, the labels are set above the code (where top-down, left-right humans expect it), not below. You can also quickly hotkey rotate through all opened files, bing, bing, bang vs. either reading through a buffer list that has nothing to do with its location in visual space, or praying that ctrl-O doesn't start opening files from a previous session, or just saying ctrl-6 (toggling between 2 measly files) is the answer.
I think the deal with Vim is that you have to keep a lot in mind, literally, as in the entire set of file names you're working with, vs. visual editors where code location is representation (i.e. its "name").
I plan to remain a member of The Church of Emacs until I die.
"One more step Please complete the security check to access benmccormick.org ... Why do I have to complete a CAPTCHA?"
What language is that? Oh, I see, thats "customers please go away" written in techie-language.
Well, I didn't learn a lot about Vim from that, but I know not to go back. Too bad, I like Vim.
What language is that? Oh, I see, thats "customers please go away" written in techie-language.
Well, I didn't learn a lot about Vim from that, but I know not to go back. Too bad, I like Vim.
Sorry, looks like you've done something to make cloudflare flag you: https://support.cloudflare.com/hc/en-us/articles/200171816-W...
I use them to manage caching and anti-DDOS for my site. Most people don't see that message, not sure what would have set it off for you. It's not a site specific feature, just a byproduct of using cloudflare.
I use them to manage caching and anti-DDOS for my site. Most people don't see that message, not sure what would have set it off for you. It's not a site specific feature, just a byproduct of using cloudflare.
Cloudflare indiscriminately flags people for using privacy-enhancing software. Please do not use Cloudflare or privacy-conscious users will be unable to use your site.
I'm looking into this now. Had never had anyone complain before. I'm not going to get rid of cloudflare, my site has been up consistently after several hours on the front page, which obviously doesn't happen for everybody. Having their caching is worthwhile. But it does seem like it's possible to disable this challenge page going forward. [1]
I'll take a look when I'm off work later.
[1]: https://support.cloudflare.com/hc/en-us/articles/200170096-H...
I'll take a look when I'm off work later.
[1]: https://support.cloudflare.com/hc/en-us/articles/200170096-H...
I find dired, tramp, org-mode, auctex, magit and good async support indispensible and the Vim equivalents are either less powerful or non-existent.