Taskwiki overrides custom mapping for <CR>

[kaiec]

Currently, I assume after fixing #17, CR is hard-coded bound to either open task info or follow a link, which is the standard mapping of vimwiki.

Vimwiki allows the remapping of CR by providing an alternative mapping for VimwikiFollowLink, which I did because I far too often create links by accident. There should be a similar way to prevent taskwiki from remapping CR.

One approach would be to check the current mapping of CR and invoke this action if not on a task, probably the only way to keep the current mapping as additional functionality for CR.

I could also live with a check that only adds the task info mapping when VimwikiFollowLink is mapped to CR. The drawback would be that I would be forced to remap task info to a different key, which then of course should be possible, too (not sure if I could do this already).

[sdondley]

I was just going to report this myself. Related to this is that when you create a vimwiki link in a task, you can't follow the vimwiki link in a task using .

[fleekix]

I just installed taskwiki and vimwiki today, and spent about half the day troubleshooting why creating/following links would not work... I can only assume this could be related?

I found that if I deleted taskwiki then it works fine. I was floored to discover that taskwiki actually interferes with the defaults of vimwiki.

[tbabej]

Taskwiki does indeed override the mapping for <CR>, the functionality works as follows:

1. Look if the cursor is on a vimwiki link (between [[ and ]] symbols). If yes, perform the same action as vimwiki would.
2. Look if the current line is a taskwiki construct (a task or a viewport). If yes, display information about the task/viewport. If no, call the same function the default binding for <CR> performs in vimwiki.
3. Perform the same action as vimwiki would.

The implementation can be found here: https://github.com/tools-life/taskwiki/blob/679e5641949ff1d97b5727eb454b9b95a7b79b37/taskwiki/main.py#L260-L295

It is possible that we were relying on vimwiki functionality that got refactored / had API changed.

[kaiec]

So, what do you think about my proposals? Is this doable?

[tbabej]

One approach would be to check the current mapping of CR and invoke this action if not on a task, probably the only way to keep the current mapping as additional functionality for CR.

I tried to explain in my previous commit above that taskwiki is already trying to implement this (see the quoted code section), so if it's failing, it's a bug and we need to dig down deeper what's happening under the hood.

[kaiec]

If I understand it correctly, you implement it "almost". By hard-coding the vim.command('VimwikiFollowLink') you basically hard-code what happens on CR for Vimwiki, while it is actually configurable. Instead you would have to invoke the Vimwiki-Command that is actually mapped to CR, if any. In my case, I removed the CR mapping in Vimwiki because it annoyed me, and Taskwiki brought it back.

[tbabej]

Ah, I see. This is indeed a special case the implementation did not think about.

[MaxPancake]

Taskwiki does indeed override the mapping for <CR>, the functionality works as follows:

1. Look if the cursor is on a vimwiki link (between `[[` and `]]` symbols). If yes, perform the same action as vimwiki would.

2. Look if the current line is a taskwiki construct (a task or a viewport). If yes, display information about the task/viewport. If no, call the same function the default binding for `<CR>` performs in vimwiki.

3. Perform the same action as vimwiki would.

The implementation can be found here:

https://github.com/tools-life/taskwiki/blob/679e5641949ff1d97b5727eb454b9b95a7b79b37/taskwiki/main.py#L260-L295

It is possible that we were relying on vimwiki functionality that got refactored / had API changed.

I'm having problems w/ step 2 - if I create a task with a vimwiki link in it (say the task is editing some vimwiki file), then according to this logic, CR would show task info instead of opening the vimwiki link. Is there a way to unmap CR for this action?

[liskin]

@MaxPancake If there's a link, you never get to step 2, step 1 follows that link.

Unfortunately it only works for vimwiki links with vimwiki syntax, so markdown links and urls don't open. I didn't like that, so I remapped CR to do what I want. Here's what I have, for inspiration: https://github.com/liskin/dotfiles/blob/e1af75ebc4de3f4391a54d500d6f5283ac868dbe/.vim/after/ftplugin/vimwiki/liskin.vim#L11 https://github.com/liskin/dotfiles/blob/e1af75ebc4de3f4391a54d500d6f5283ac868dbe/.vim/autoload/vimwiki/liskin.vim#L4-L13 Not pretty, but works.

[MaxPancake]

@liskin thanks for the clarification. I use markdown, so the taskwiki mapping overrides vimwiki's for CR. I ended up remapping the keys for vimwiki to open links..

[mr-majkel]

I'm also on markdown syntax and <CR> is not allowing me to follow the links if the link is a header. For the time being I have remapped the VimwikiFollowLink, but it is suboptimal solution.

[crates51]

What helped me in nvim lua config with markdown syntax was to unmap <CR> when entering vimwiki filetype like so:

vim.api.nvim_create_autocmd("FileType", { pattern = "vimwiki", command = [[unmap <buffer><silent> <CR>]] })

in the after folder

in simple vim would be like this i think:

au filetype vimwiki silent! unmap <buffer> <CR>

i think it only worked in my case, but you might give it a shot.

EDIT: P.s. you'll also need to map back CR to <Plug>VimwikiFollowLink