-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
Comments
I personally think that we have enough options already to control key settings. You can just set all the mappings to Some of them also follow the convention - e.g. 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 I also think that there are a lot of settings already. 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 |
|
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 |
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.
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? 😃😃😃 |
We would/could hide errors from there, of course - and/or check if a map exists already. |
Also removes section for deprecated `goto_definitions_command`. Ref: davidhalter#213 Closes davidhalter#943
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.
The text was updated successfully, but these errors were encountered: