AndrewRadev

14 ปีที่แล้วdiscuss

Well, in your case, you could put a definition for javascript. The built-in "ruby hash style" transformation should work for this:

    " in ftplugin/javascript.vim
    let b:switch_definitions =
          \ [
          \   g:switch_builtins.ruby_hash_style
          \ ]

With this, in a javascript file, you can turn ":foo => 'bar'" entries into "foo: 'bar'" ones.

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.

AndrewRadev

14 ปีที่แล้วdiscuss

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:

    create(:user, :active => true).should be_active

Now, I want to change its properties and assert the opposite. I duplicate the line, change the property, and switch the "should" into a "should_not":

    create(:user, :active => false).should_not be_active

This is a very simple example, but I do things like this on a regular basis while writing tests. I assume other people have different workflows around this, but this works nicely for me. That's why I mentioned in the video that these are my own little timesavers, so you might not find them that useful :).

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.

AndrewRadev

15 ปีที่แล้วdiscuss

I'm not really a Django user, but I was interested in the Vim section of the post. I work with Rails and my personal approach to setting framework-specific commands, mappings, etc. is by using the proj plugin: http://www.vim.org/scripts/script.php?script_id=2719. It's fairly simple, it just sources a project-specific vimfile when you tell it to. I keep a ton of settings in "~/.vim/projects/rails.vim" and I place a "runtime projects/rails.vim" in the project file. This kind of a workflow might give you more freedom in customizing your vim for Django projects, but it really depends on whether you can get used to that. Just a suggestion :).

comments