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

Modify key binding ways for compation with vim-which-key #112

Closed
Mayrixon opened this issue Jul 29, 2020 · 6 comments
Closed

Modify key binding ways for compation with vim-which-key #112

Mayrixon opened this issue Jul 29, 2020 · 6 comments
Assignees
Labels
plugin:conflict conflict when mkdx is used in conjunction with other plugins

Comments

@Mayrixon
Copy link

Modify key binding ways for competition with vim-which-key

Hello, thanks for the efforts on providing this fantastic plugin. I love some shortcuts provided, such as the one can convert CSVs to tables.

However, I found this plugin cannot work with vim-which-key, a plugin aiming to help people remember shortcuts. I am using <space> as the leader key, but mkdx cannot be activated when I map the prefix to <leader> or <space> with vim-which-key.
I have tested map mkdx's prefix to , or even ,, and these shortcuts can works properly.

I am also using NERD commenter and easymotion. These two plugins can both work with vim-which-key but in different cases. NERD commenter's shortcuts can be recognised by vim-which-key automatically, but easymotion's shortcuts cannot be displayed while works properly. For your convenience, NERD commenter's key bindings can be found here, and easymotion's key bindings could be found here.

@SidOfc
Copy link
Owner

SidOfc commented Jul 30, 2020

Hello @Mayrixon!

Thanks for the positive message and feedback! One interesting thing I'm seeing is that both these mapping scripts live in the /plugin folder whereas mkdx mapping script lives in /ftplugin e.g. it only binds mappings after opening a markdown file, and the mappings only exist within markdown buffers.

I don't see any specific code in vim-which-key to enable/register filetype plugin mappings so I doubt it will be possible to add support for it in mkdx due to it being a filetype plugin rather than a global one.

Alternatively, if there was a way to programmatically add filetype specific mappings I think I could implement support for it in mkdx, but that would require the author(s) of vim-which-key to support this scenario.

That said I could have missed something as well, do you have an example of a filetype plugin that works with vim-which-key?

@SidOfc SidOfc self-assigned this Jul 30, 2020
@Mayrixon
Copy link
Author

Thanks for the quick reply!

There is no specific command in vim-which-key to enable filetype plugin mappings, but we can do this kind of work with autocmd FileType. I can demonstrate this later.

I didn't notice the mapping script locations. Luckily, I found vimtex is using scripts in folder /autoload and /ftplugin mapping shortcuts. I think it would be more clear if you can have a glance. The key mapping function could be found here.

As I mentioned, I'm using vim-which-key to manage shortcuts. In my .vimrc, I am using autocmd FileType tex let g:localleader_key_map.l = { 'name': '+vimtex' } to register vimtex shortcuts only if the filetype is tex. I have also tested let g:localleader_key_map.l = { 'name': '+vimtex' } in files whose type are not tex, and the shortcut menu was empty as expected because vimtex's init function locating in `/ftplugin'.

@SidOfc
Copy link
Owner

SidOfc commented Jul 30, 2020

I see, it doesn't seem too different from mkdx actually. The actual "mapping" is created via a function instead of directly inside a for loop which is what mkdx does. Still, vim-which-key is able to pick these up so it should be able to pick up mkdx as well I think.

I'll try adding this plugin to my vimrc to see if I can make it work, though I'm not sure whether it'd be done this week, I'll keep you posted!

SidOfc added a commit that referenced this issue Jul 30, 2020
…y skip mapping when exact mappings are found (#112)
@SidOfc
Copy link
Owner

SidOfc commented Jul 30, 2020

@Mayrixon I think my previous commit fixes the issue. I used the mapcheck builtin to validate that a mapping hadn't already been mapped before creating the mapping via mkdx. The thing is that mapcheck acts like "starts with" so in this case, because <leader> was already mapped, it skipped the mappings.

I am now using maparg instead which requires an exact mapping to the same combination to exist. This means that while <leader> is mapped, it will still create mkdx <leader>b mapping because it is not an exact match.

I tested it using:

let mapleader = ' '
nnoremap <leader> :<C-U>WhichKey '<Space>'<Cr> " didn't use <silent> in order to allow debug / error messages

and this was the result in a markdown buffer:

image

It's pushed to master as it is a reasonably safe change to make, can you verify things are working as expected on your end, or whether more issues pop up?

And of course, cheers so far with the feedback, always appreciated!

@Mayrixon
Copy link
Author

I have tested with my settings and everything works perfectly. Thanks for your help!

@SidOfc
Copy link
Owner

SidOfc commented Jul 30, 2020

No problem, cheers for the quick test and enjoy :)

@SidOfc SidOfc added the plugin:conflict conflict when mkdx is used in conjunction with other plugins label Jul 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin:conflict conflict when mkdx is used in conjunction with other plugins
Projects
None yet
Development

No branches or pull requests

2 participants