Repository: vim-vdebug/vdebug

Issue #323: Provide commands instead of mappings by default
Created: 2018-02-22T12:16:08Z
There is quite some asymmetry between functionality that is provided by python functions, functionality that is provided by Vim commands and stuff that is accessible through mappings.
I suggest we provide a uniform set of Vim commands (or Vim functions, I don't mind, they might be easier when handling arguments) that provide all things that the user should be able to with vdebug.  The documentation should then encourage the user to only use these. The python bindings should be hidden internally (I think they already are). If we provide commands for all functionality the plugin will also be easier to explore for new users: They can type :Vdebug<TAB> and see what commands are suggested – and be sure that that is all you can do with the plugin!
If we want to provide default key mappings they should map to the aforementioned vim commands/functions directly! That way they are easier to understand for users. Also they are easier to mimic in case a user wants some custom mappings.
Currently we have g:vdebug_keymap which could be used for custom mappings. But the keys in that dict are used nowhere else in the public interface. We could keep this dict and try to adjust it to the new commands, or we can replace it with a simple boolean var like g:vdebug_use_default_mappings which the user can set to false in order to just map stuff individually.
The help file also lists several commands in section 4.3 that are not available (for me?). For example VdebugCommandStepOver which is only accessible via <F2> (but as mentioned above the key for that is called step_over and not VdebugCommandStepOver).
What do you think about providing a uniform interface and better exploreability for vdebug? What names would you suggest for the commands?

Duplicate issue #493: Make mappings simpler and abstract
Created: 2020-11-15T23:59:57Z
There is still no abstracion that prevents from direct binding physical keys to actions. Vdebug still forces the user to overwrite existing physical mappings by default (from g:vdebug_keymap_defaults). For example, I lose nmap <F12> this way after running vdebug although the piece of (Python) code to keep old mapping seems to exist.
I would like to hide mapping of low-level operations behind an abstraction. For example
nmap <Plug>(vdebug-run) :python3 debugger.run()<CR>
does not overwrite any existing user mapping. The user would then have to create some custom mapping like
nnoremap <F5> <Plug>(vdebug-run)
We could also provide the old-style mapping to keep backward compatibility (and provide such physical mappings that can be disabled with one setting).
In this case, we can check the code used to store / restore mappings as long as we need it.
The cheapest, non-perfect  way could be to add
let g:vdebug_keymap_defaults = {
\    'run' : '<Plug>(vdebug-run)',
" ...
and keep the old hardcoded mapping to allow the user to select the old set.
Now, without changing any line of Vdebug code, we can also replace all default physical keymaps by abstract at the user side:
let g:vdebug_keymap['run'] = '<Plug>(vdebug-run)'
but it should be provided by Vdebug.

Closing comment (2020-11-16T06:58:40Z): Related to #323