4 ms·
But that was what Ornstein meant by cheatsheet. Anyways, why did you "want to learn Vim for a long time", did you feel limited by st?
by jumpwah 12y ago
But that was what Ornstein meant by cheatsheet. Anyways, why did you "want to learn Vim for a long time", did you feel limited by st?
- delongshot 12y agoRight, I thought I heard him mention it, but couldn't remember where. Looks like he mentions it in this post >> http://robots.thoughtbot.com/the-vim-learning-curve-is-a-myth http://robots.thoughtbot.com/the-vim-learning-curve-is-a-myt... And really, I wanted to learn so I could pair with other programmers remotely. I had heard that many were using tmux and Vim so I thought it was time.
- jumpwah 12y agoI don't remember where exactly either, but I think in multiple videos/talks of his, one of his top tips if you're new, is to make a list of your top 5 or so new commands you'd like to learn/focus on each week and keep using or referring back to them so that it starts becoming muscle memory. And fair enough, was just curious why you kept persisting. :p
- briandear 12y agoVim is much more efficient. For example, within Tmux, one never needs to leave the terminal; with ST, there's a frequent switching cost which compounds over the course of a day. If one were to put Tim Pope up against an ST master, it's almost certain Pope would win.
- wyclif 12y agoI love the iTerm2 + tmux + vim + zsh environment. It takes a little time to figure out how to juggle the configuration for them, but once you do, it's super efficient.
- joshfinnie 12y agoAre you dotfiles openly available? I have the same set of tools, but still find things are slightly off... would love to compare notes.
- gcao 12y agoI'm using the same setup (plus spf13.vim, powerline and Oh My Zsh). It looks beautiful and works very well. Here is a screenshot of my setup: http://postimg.org/image/9jqokq0ll/full/ http://postimg.org/image/9jqokq0ll/full/
- jumpwah 12y agoWell I guess it depends on what you do. That might be true if you use only console based (tui/cli) programs to do your work, but in your workflow, is there any non-console program you use? I'm not trying to make some sort of opposite point here, tmux is awesome, but I'm just actually curious, assuming your work is in programming of some sort (since this is hn), do you use a 'graphical' program in your workflow? I'm not a programmer but do like hobby programming stuff, and so when I do, I usually have to use a browser to look up documentation of things, possibly even look up bug report threads and sometimes various other things. The browser I believe has to be graphical (while terminal browsers can be very useful, I don't think it's very practical for the majority of your web browsing tasks to be handled solely in a tui browser these days), and so if you do use a graphical browser in your workflow, i.e. when you are working (not playing/procrastinating), that would mean you would have to leave the terminal. It could very well be that you do not need to leave the terminal since you're already familiar with your language/framework whatever so you don't need to look up documentation like I do (coz I'm hobbying). But regardless, my next question would be when you say "with ST, there's a frequent switching cost which compounds over the course of a day". But wouldn't that be the same with switching between the tmux pane/window/tab with vim in it to the one with a terminal open? Or do you just ctrl-z and fg back and forth in vim? But then ctrl-z + fg is still a form of switching, just different to tmux pane switching. Perhaps you meant that one never has to move their hands away from the keyboard to go to the mouse (like you would in st), as opposed to leaving the command line of the terminal/tmux (as you would with both vim and st)? And the point would be something like, needing to move hands repeatedly to and from the mouse and keyboard not only pays a toll on speed (of text editing), but also not ergonomically comfortable... etc? If that's the case, yeah I agree. But you might say that leaving the terminal means switching to a graphical program which means needing to use the mouse... etc. You would be right, except my point is that, that might not necessarily be the case and hence it's 'more correct' to say leave the keyboard than just leave the terminal. For example, in my workflow (for hobbyist programming that is), I sometimes need to use the graphical program, firefox, yet I do not need to leave the keyboard due to pentadactyl. Even outside that workflow, I do not need to leave the keyboard in varous other graphical programs such as video player, image viewer and pdf viewer. You might say that to run a graphical program, the very act of switching windows requires the mouse because you'd typically have to use a mouse based graphical window manager program of some sort so that you could even lay out/draw and switch between the boxes/widnows in which graphical programs exist within. But as long as the platform supports it, the window manager could be configured to have keyboard shortcuts to handle anything the mouse can achieve, or maybe you could even replace the default moused based window manager with a keyboard based one. Anyways, my question to OP was coming more from his point of view, if he's already comfortably using st, why consider switching to vim, especially after multiple failed attempts? Perhaps he wasn't actually completely comfortable with st and was seeking for something else to solve that, or maybe he heard or saw something about vim that attracted him? As a vim user myself, I already knew that vim is more efficient than any other editor ever, but I'm still always curious to learn about what attracts new users to it these days when all the hype seems to be about newer or more 'contemporary' editors like atom and st, especially if I find something new that I didn't already know about vim. And so I asked him as he didn't state why specifically in the article. (And the article itself didn't mention anything about why vim was special to him either, so I couldn' really infer.) I asked about st specifically though because I don't know much about it, and so the more I can learn about it, the more I can hopefully confirm to myself that vim is indeed objectively faster/better than st, and hence more peacefully sleep at night. To the reading non-vim user, when I say "faster/better than", I mean a really good vim user versus an equally really good st user. If you don't enjoy using vim, or just do not 'click' in vim's general way of operating, obviously you will be slower and worse in vim than with your editor.