Fix hardtime changing mappings between modes

[V1OL3TF0X]

I discovered it because I have those mappings:

vim.keymap.set('n', 'J', 'mzJ`z')
vim.keymap.set('v', 'J', [[:<C-u> execute "'<,'>m '>+".v:count1<CR>gv=gv]])
vim.keymap.set('v', 'K', [[:<C-u> execute "'<,'>m '<--".v:count1<CR>gv=gv]])

I recently changed the last two from

vim.keymap.set('v', 'J', ":m '>+1<CR>gv=gv")
vim.keymap.set('v', 'K', ":m '<-2<CR>gv=gv")

and wanted to add them to hardtime - to my surprise, the functionality broke down.

After investigating I found that mappings which hardtime uses gets only mappings from normal mode, in turn replacing v mapping with n mapping for J after I enabled them in my hardtime config

[m4xshen]

plz format the code with StyLua :)

[V1OL3TF0X]

plz format the code with StyLua :)

@m4xshen done ;)

[V1OL3TF0X]

@m4xshen any updates on this?

[m4xshen]

heyy @V1OL3TF0X sorry for the late reply. Could you please clarify what bug this PR is intended to fix?

[V1OL3TF0X]

Sure thing! The bug was as follows:
If a user has a mapping for a key (let's say J, like in my case) that is different for multiple modes, after hardtime is enabled to track said key all of the mappings have the functionality of normal mode.

Steps to reproduce:

1. Add keymaps for same key, different modes:

vim.keymap.set('n', 'J', function() vim.notify('Normal!') end)
vim.keymap.set('v', 'J', function() vim.notify('Visual!') end)

2. Add key and both modes to hardtime config under restricted_keys:

opts = {
    restricted_keys = { J = { 'n', 'v' } },
}

3. Try to use mapping in visual mode:

Expected: "Visual!"
Actual: "Normal!"

(I hope that is a sane explenation of the bug, if not - lmk)

[m4xshen]

Thanks, that's super clear and I can reproduce it! I'll take a look at your PR :)

[m4xshen]

When I call :Hardtime disable, h j k l keys stop working. I guess it's related to the changes here.

[V1OL3TF0X]

The change was meant initially to not remove user mappings when disabling hardtime, I guess it went a little too far
I changed it to disable / enable not modifying mappings but early returning in handler - lmk if that's okay or should I try to preserve the current logic of modifying mappings.
The way I see it it can work in 3 ways:

• disable deletes the mapping if no user mapping existed and sets the mapping to original mapping if it did - that is the closest to the original approach
• disable overrides handler to early return - current implementation, simple but might have perf overhead
• disable changes the handler to get_return_key - the approach that was bugged, I think it was just missing return in the statements.
  I see upsides and downsides of all of the approaches, so I'll go with whichever you find preferrable.

[V1OL3TF0X]

@m4xshen after giving it some thought I decided to go with option one, it seems like it can cause the least side effects, especially when repeatedly toggling hardtime