Jedi-vim: Add an option to disable key bindings

Created on 13 Nov 2013  路  13Comments  路  Source: davidhalter/jedi-vim

Hey,

Would you be willing to add an option to disable binding keys? (Apologies if it exists already, I only see g:jedi#auto_initialization = 0 but that disables more than just mappings).

I know you can remap each key to make it use a different key, but that means that users have to go look up each map and pick some other key, even if they don't care about it (i.e., I just want Jedi to not quash my mappings, I don't really care about all the functionality it's mapping).

Another alternative (or something to consider) based on the above would be to not map keys if they're already mapped to something else.

discussion

Most helpful comment

I agree with @Julian, I would like a feature like this as well, especially since I don't use jedi-vim as much by itself rather than integrate it into existing completion frameworks (such as deoplete, neocomplete) so that it is consistent with other languages I program in.

I think the best solution is to use the mapping and have a setting to disable the mapping, or something equivalent.

All 13 comments

I personally think that we have enough options already to control key settings. You can just set all the mappings to "" and nothing will happen to your settings anymore. Considering that it's just 6 settings (and you probably won't disable all of them because you want some of them!)

Some of them also follow the convention - e.g. K and <Ctrl-Space> - most people use those commands like that - consider also that jedi-vim is not the library that adds a thousand commands, the commands haven't changed in about a year! New commands would imply new major functionality in Jedi and that's really hard to do.

So I guess if this is not a general problem (for more people) I would be closing this issue.

OK, no worries :)

I generally get frustrated when I install a library and it squashes some important mappings and then I have to go look at its documentation to be sure what it did and turn it off, so that I can selectively turn some on.

I've gotten things down at this point, so I'm OK with closing this if it's not something you're interested in.

Thanks for considering (and for the library of course) :).

yeah, sorry mate, I can understand your worries. I just started to be conservative with creating new API functionality because it's also important to make everything as easy as possible.

Also keep in mind: jedi-vim is a very small library (the VIM part) of course there's some more complicated parts - in the jedi library - but that has nothing to do with the VIM integration. VIM integration is very basic. There's almost nothing complicated going on (except the function pop ups).

Sorry to post on an old issue, but I still think this would be a useful feature. I, too, was looking for an option to disable setting of the default keymappings (without turning off other initialization steps, e.g. omnifunc).

That said, I respect that you want to keep jedi-vim's configuration/API small.

We might at least use :map-<unique>, which would display an error if a mapping is used already.
Or to be more friendly: check this ourselves and provide helpful instructions.

I also think that there are a lot of settings already.
Best practice would be to use <Plug> mappings, instead of settings for the left-hand-side of the map.
We could then check if a map to something is provided already (which means the user has defined it manually).

But it would need to handle the old settings for B/C and therefore it's probably not worth it.

I personally still think that the current way is ok. I would be willing to use unique, if that helps. But I don't really want to add new settings.

unique is the wrong direction (would be worse) IMO. It's my mapping I want, jedi shouldn't cause errors on startup :).

Just as another example of why the current solution isn't nice to users (well, really to me, I can't speak for anyone else), a recent commit broke my leader mappings once again, because g:goto_command was added, which I wasn't overriding.

I agree with @Julian, I would like a feature like this as well, especially since I don't use jedi-vim as much by itself rather than integrate it into existing completion frameworks (such as deoplete, neocomplete) so that it is consistent with other languages I program in.

I think the best solution is to use the mapping and have a setting to disable the mapping, or something equivalent.

You're welcome to provide a PR.

I don't use jedi-vim as much by itself rather than integrate it into existing completion frameworks (such as deoplete, neocomplete)

But then you still use the goto-mappings etc, no? deoplete-jedi ships its own jedi, and does not require jedi-vim.

I could imagine having one setting to not define any automatic mappings.

But me nor David won't do it, so you need to contribute (and support it).

Hi there, I'm a new commer here.

It has been discussed 6 years, and I got the honor to add 3 lines of code to make this contribution?

馃槂馃槂馃槂

unique is the wrong direction (would be worse) IMO. It's my mapping I want, jedi shouldn't cause errors on startup :).

We would/could hide errors from there, of course - and/or check if a map exists already.
But in general I think having an explicit setting for this makes things easier. (#943)

Was this page helpful?
0 / 5 - 0 ratings