Code Substitution Done Right - Switch.vim(vimninjas.com)
vimninjas.com
Code Substitution Done Right - Switch.vim
http://www.vimninjas.com/2012/09/12/switch/
13 comments
I don't get it. How often do you need to change between complete opposites? (should/should_not, true/false, &&/||) And what's the point of changing "predicate?" to "true and (predicate?)" or "false or (predicate?)"
I wrote a similar plugin called vim-cycle, it's a bit different but basically the same concept.
https://github.com/zef/vim-cycle
I really use it all the time and find it extremely useful, but not exactly in the way he seems to in the video. One of the ways I frequently use it is for CSS, where there are related words that can frequently change, like margin/padding, top/bottom, class/id, png/gif/jpg, absolute/relative, or in Ruby if/unless, present/blank, else/else if. Things like that...
The mapping I use is the same as is used to increment and decrement numbers in Vim, which is very natural to me so it's a really easy way to switch things much more quickly than typing them.
You can see the pairs I define by default in my plugin here:
https://github.com/zef/vim-cycle/blob/master/plugin/cycle.vi...
https://github.com/zef/vim-cycle
I really use it all the time and find it extremely useful, but not exactly in the way he seems to in the video. One of the ways I frequently use it is for CSS, where there are related words that can frequently change, like margin/padding, top/bottom, class/id, png/gif/jpg, absolute/relative, or in Ruby if/unless, present/blank, else/else if. Things like that...
The mapping I use is the same as is used to increment and decrement numbers in Vim, which is very natural to me so it's a really easy way to switch things much more quickly than typing them.
You can see the pairs I define by default in my plugin here:
https://github.com/zef/vim-cycle/blob/master/plugin/cycle.vi...
I'm the plugin writer. The should/should_not dance is something I keep doing when I write tests. Say I create a user with certain properties and I assert something about them:
As for the predicate stuff, it's actually "true or (predicate?)". The idea is that switching to this would result in the first branch always being executed, unconditionally. I use this for view templates when I want to see how the page looks when, for example, there's no logged in user (it'd take more time to log out and then back in :)), or when the user has no trading accounts, or some other simple condition that I want to disable for just a sec to check out if some div got misaligned.
Really, the basic idea is simple -- if there's some code that you often need to change into some other code, you could store that transformation as a "switch" and avoid repeating yourself.
create(:user, :active => true).should be_active
create(:user, :active => false).should_not be_active
As for the predicate stuff, it's actually "true or (predicate?)". The idea is that switching to this would result in the first branch always being executed, unconditionally. I use this for view templates when I want to see how the page looks when, for example, there's no logged in user (it'd take more time to log out and then back in :)), or when the user has no trading accounts, or some other simple condition that I want to disable for just a sec to check out if some div got misaligned.
Really, the basic idea is simple -- if there's some code that you often need to change into some other code, you could store that transformation as a "switch" and avoid repeating yourself.
I'm guessing the latter is intended to help you add more conditions. Switch "if foo?" to "if true and (foo?)", which has the same meaning, then replace the "true" to get "if bar? and (foo?)". Seems unlikely to save much time in the long run, but there you have it.
I'm seeing a few places this will come in handy:
* toggling booleans in a config file.
* switching a string literal between 'single quotes', "double quotes #{so I can add interpolation}", and :symbols. I do this pretty often. The former is easy enough with surround.vim (cs'"), but the latter is a pain (ds'bi:<ESC>)
* the ability to add a "tap" and remove it with a single key combo is interesting for debugging.
* toggling booleans in a config file.
* switching a string literal between 'single quotes', "double quotes #{so I can add interpolation}", and :symbols. I do this pretty often. The former is easy enough with surround.vim (cs'"), but the latter is a pain (ds'bi:<ESC>)
* the ability to add a "tap" and remove it with a single key combo is interesting for debugging.
Annnnnd another tutorial that shows me how vastly underwhelming my vim skills are.
Though looking back a year ago, I struggled to navigate, let alone copy and paste. Step at a time, right? RIGHT?!
Though looking back a year ago, I struggled to navigate, let alone copy and paste. Step at a time, right? RIGHT?!
I recently moved to vim as well. Everything I'm doing I'm pretty much aware that I could probably be doing it in some superdooper quick way...
I'll get there though. Eventually.
I'll get there though. Eventually.
Just keep going and refrain from copying verbatim other people's config and using too many plugins.
Just check out `:help index` when you get bored, scroll some random amount down, and use a new thing or two that day.
This looks cool but I'd like filetype-independent definitions. For example, to convert a ruby dictionary pasted into a .js file.
Well, in your case, you could put a definition for javascript. The built-in "ruby hash style" transformation should work for this:
If you do need global (non-filetype) switches, you could define some by placing them in the g:switch_definitions variable. Read up on the docs if you want more information.
" in ftplugin/javascript.vim
let b:switch_definitions =
\ [
\ g:switch_builtins.ruby_hash_style
\ ]
If you do need global (non-filetype) switches, you could define some by placing them in the g:switch_definitions variable. Read up on the docs if you want more information.
[deleted]
So I'll pass on this plugin for the time being. That said, this new blog is fantastic and I'm bookmarking all the articles for later.