search

jeetsukumaran / vim-indentwise

A Vim plugin for indent-level based motion.
220 stars 17 forks source link

Default mapping [% / ]% conflicts with matchit.vim plugin #6

Open inkarkat opened 9 years ago

inkarkat commented 9 years ago

I like the added [% / ]% motions to move to the beginning / end of the current block, but unfortunately, they conflict with the matchit.vim plugin that ships with Vim (cp. :help [%). As many users associate % with matching braces, I'd suggest a different default mapping, maybe [; / ];, as these are close together (on a US-English keyboard, anyhow), close to the other keys used by the plugin, and ; (the command separator in many programming languages) at least somewhat suggest current coding block.

PS: While submitting my patches, I noticed that you've actually based your plugin (with proper attribution, thanks!) on the code I've once posted on the Vim Tips Wiki. In fact, I had used the code I've posted there for years, and only recently discovered and then switched to your plugin (as it looked more advanced). Keep up the good work!

jeetsukumaran commented 9 years ago

Strangely enough, it seems that matchit.vim is not installed for me (I am using MacVim). Hence I missed this mapping. You are right about avoiding conflict. I wonder if [0 and ]$ might be better mnemonically? Or [^ and ]^ to preserve the symmetry?

inkarkat commented 9 years ago

I had considered all of those, too. I don't like the asymmetry of the first, and [^ has been in use by me personally. In the end, it's a tough decision, as so many keys are already taken.

jeetsukumaran commented 9 years ago

Another possibility is [<BS> and [<BS], but I suspect people will not not like the difficulty of typing this.

By the way, thank YOU for posting the code on the Vim Tips Wiki that this plugin is based on!

blueyed commented 8 years ago

Came here to report the same conflict.

My 2 cents: I like [<BS> and ]<BS>, given that it is near [ / ] on a German keyboard, which I've mapped to ü/+, and that's right next/below <BS>.

Apart from that, I would find it more useful if it ([%) would jump to print(1) (the first line of the function body) with the cursor on the last line.

def some_long_method_name(foobarbaz1, foobarbaz2, foobarbaz3, foobarbaz4,
                          foobarbaz5):
    print(1)

    foo = another_long_method_name()

Currently it is described as follows:

move to the line just after the previous line of lesser indent

Maybe that could be made to stop before lines with more indent?!