Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an option to disable key bindings #213

Closed
Julian opened this issue Nov 13, 2013 · 13 comments
Closed

Add an option to disable key bindings #213

Julian opened this issue Nov 13, 2013 · 13 comments

Comments

@Julian
Copy link

Julian commented Nov 13, 2013

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.

@davidhalter
Copy link
Owner

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.

@Julian
Copy link
Author

Julian commented Nov 13, 2013

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) :).

@Julian Julian closed this as completed Nov 13, 2013
@davidhalter
Copy link
Owner

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.

@davidhalter
Copy link
Owner

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).

@sloria
Copy link

sloria commented May 4, 2015

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.

@blueyed
Copy link
Collaborator

blueyed commented May 4, 2015

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.

@davidhalter
Copy link
Owner

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.

@Julian
Copy link
Author

Julian commented May 5, 2015

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

@Julian
Copy link
Author

Julian commented Jun 2, 2015

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.

@dbrodie
Copy link

dbrodie commented Oct 27, 2016

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.

@blueyed
Copy link
Collaborator

blueyed commented Oct 27, 2016

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).

@kadaliao
Copy link

kadaliao commented Aug 21, 2019

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?

😃😃😃

@blueyed
Copy link
Collaborator

blueyed commented Aug 21, 2019

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)

blueyed added a commit to blueyed/jedi-vim that referenced this issue Aug 22, 2019
Also removes section for deprecated `goto_definitions_command`.

Ref: davidhalter#213
Closes davidhalter#943
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants