Tom Ryder writes about Unix tools, Vim, shell usage and older utilities such as ed.
HN commenters say they learned a great deal about Vim and obscure but historically important Unix tools, and single out the Vim koans as a favourite.
Also cool to play around with are the various options that let GCC (and presumably LLVM) show you the various compilation stages of your C code. You can even spit out the C and resulting assembly side-by-side.
I haven't had the time to play with this, but Part 4 of the excellent "Unix as IDE" series [1] goes into it and I'm sure there's more around the web.
Another really fun way to get into the underlying assembler that the C compiler generates is Vidar Hokstad's "Writing a compiler in Ruby, bottom up" [2]. This series involves writing little C functions, compiling them to the simplest assembly you can get, then writing a ruby compiler (in Ruby!) that emits that assembly. Some people have objections to the approach, but it's really quite nifty. I especially like it because it's really refreshing to see a compiler tutorial that doesn't start with the lexer and parser.
[1] http://blog.sanctum.geek.nz/unix-as-ide-compiling/
[2] http://www.hokstad.com/compiler
You were wrong, obviously, but the people who made you believe that with their stupid blog posts are wrong, too. I'd say they are more wrong than you.
Those blog post are seriously misleading: at best, one can come up with a vim config that make it look like a stereotypical IDE: file tree on the left, class tree on the right, quickfix at the bottom, completion… But there's a lot more to an IDE than that. Because Vim will never understand your code as an IDE does it will never be an IDE, full stop.
It can be the (super charged) editor module of your development environment but it would take a lot more than a blog post with cool screenshots to explain how and why. Even this 7 parts series is probably not enough: http://blog.sanctum.geek.nz/series/unix-as-ide/
> Even after 1-2 weeks
You should accept a longer trajectory -- say 1-2 years to learn it and 7 years to get good at it. But even then it means you need to review things you do, look for repeated patterns and wonder about/hunt down smarter ways of doing things.
A big help for me when starting was hanging out in the Vim IRC channel (Freenode, I think). This stackoverflow reply is a classic on how to learn Vim: https://stackoverflow.com/a/1220118/4751065
Bairui's blog has some good stuff, but sadly he left the IRC channel in 2015 then I guess: http://of-vim-and-vigor.blogspot.com/?m=1
Finally, of course, the koans: https://blog.sanctum.geek.nz/vim-koans/
According to Wikipedia (I know, not the most reliable source) a Kōan is a story, dialogue, question, or statement, which is used in Zen-practice to provoke the "great doubt", and test a student's progress in Zen practice.
The main themes in this particular article are that Vi is not a silver bullet, that even using a great tool you can do a lousy lob and that tools are just tools.
So more than an "incoherent flamebait" this is a list of Kōans about Vi created by someone that uses it and other Unix tools on a daily basis (as you can see on his other posts: http://blog.sanctum.geek.nz/)
This is the efficiency post that I kept coming back to when starting to use the command line more:
http://shebang.brandonmintern.com/tips-for-remote-unix-work-ssh-screen-and-vnc
I'm seeing a lot of people respond about using similar setups with different tools. It doesn't really matter whether you use awesome/xmonad/ratpoison or something else, but I can tell that the people who built the tools I use think about computers the same way I do (https://wiki.archlinux.org/index.php/The_Arch_Way). I'm striving for this:
http://blog.sanctum.geek.nz/series/unix-as-ide/
> I've never understood why people and to extend vim to try to make it half of an IDE.
Because vim ships with any *nix machine and provides a consistent experience no matter where you use it.
Vim is the DE part and people add plugins or whatever to enrich the text editing experience with LSPs or other language aware plugins, and the I in IDE is in the form of the integration with the tooling already available on the host.
This[0] might shed some better light on the "why"
[0] https://blog.sanctum.geek.nz/series/unix-as-ide/