SidOfc / mkdx

A vim plugin that adds some nice extra's for working with markdown documents
https://www.vim.org/scripts/script.php?script_id=5620
MIT License
482 stars 13 forks source link

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

Closed Mayrixon closed 4 years ago

Mayrixon commented 4 years ago

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 commented 4 years ago

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?

Mayrixon commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

SidOfc commented 4 years ago

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