Added support for repeat.vim.

[rdnetto]

This patch allows stepping in, etc. to be repeated using the '.' key.
It adds a dependency on tpope's repeat.vim. (Detecting if it is available is non-trivial as it is autoloaded, so making it optional is somewhat tricky.) I suspect most people who are interested in using vim-vebugger probably have it installed already anyway, so it probably doesn't matter too much.

[idanarye]

I'm afraid I'm going to have to reject this one. Vim's repeat command is for repeating text changes - the common use is to do a change, move the cursor somewhere else, and hit . to do the same change there. When I use repeat, I expect the last text change to repeat - not other stuff I did in-between like moving the cursor or saving the file.

So - if I do a textual change, call vebugger's step-over, and press repeat, the current behaviour(which is also the one I expect) is that the text change will be repeated. Instead, you suggest that the step-over will be repeated. Not to mention the fact that step-over is not undoable - which means that after I do this mistake, I can't hit u to undo it...

As a side note - repeat doesn't have to be a mandatory requirement. While it's true that it's hard to detect the presence of autoloaded functions - in repeat's case you don't have to. All you have to do is call it with silent!, as Tim Pope demonstrates in the plugin's README.

[rdnetto]

In that case, what if I removed the call to repeat#set, but left the VBGrepeat mapping in? (Alternatively, I could just hide the call to repeat#set behind a setting that is disabled by default.)

The main motivation for this patch is that it's a pain to type '\di' to keep stepping forward, but adding a single-key mapping to each of the step commands is just wasteful. I think there is a strong argument for the convenience of being able to repeat the last vebugger command, it's just that using '.' for it might not be the best idea.

[idanarye]

repeat.vim works by storing the last repeatable command's info in global variables. You can probably do the same with your own global(or script) variables, and make you own keymapable command for repeating them.

[rdnetto]

The problem is there's no nice way to get the last vebugger command performed without some kind of hook in the plugin. You can get the last ex command using the : register, but that can be overwritten by other ex commands and doesn't include commands performed via maps. AFAIK, the only effective way to handle it in a vimrc is to redefine all of the commands and mappings used for vebugger to call a wrapper function.

I suppose in the end the code doesn't look too different either way, although I can't help but think that if you've got to the stage where you're redefining most of the plugin's UI layer, it would just make more sense to patch the plugin itself...

[idanarye]

Maybe I explained myself wrong. I didn't say not to register the last vebugger command in some hook inside the plugin - what I said is not to register them using repeat.vim's repeat#set. Instead, use your own function and/or variables. That way you can define your own keymap for repeating and don't have to use ..

[rdnetto]

OK, so something like this then?

(Obviously it needs documentation and the remaining commands should be fixed to use the wrapper function for consistency - I just wanted to make sure I understood you correctly regarding how the hook should be defined.)

[idanarye]

What is VBGpostcmd?

[rdnetto]

A function to be defined in the user's vimrc (i.e. the aforementioned hook), which is called after each vebugger command. Said function can be used to set global variables (enabling a 'repeat vebugger command' mapping), call repeat#set, etc. as per the user's preference.

[idanarye]

If you are making an extension hook, make it right. The main users of extension hooks are not human Vim users, but other plugins that extend Vebugger. But such plugins will have to ask the user to call the plugin functions inside the user's VBGpostcmd. If we'll want to add other hooks - e.g. - VBGprecmd - and a plugin uses both, users of that plugin will have to add both calls to their .vimrc. And what if a plugin that was only using VBGpostcmd wants to release a version that also uses VBGprecmd? They'll need to somehow tell their users to update their .vimrc. Do you think all users read all the newsletters before they update?

Personally, I think that having a post-cmd just for registering the command is an overkill, but if you still want this extension hook I suggest a different approach:

1. The registration will be hard-coded. BTW - Vebugger always hold a dictionary for the currently running debugger - I suggest you keep that data there. It's s:debugger in autoload/vebugger.vim, and you can get it with vebugger#getActiveDebugger.

2. Instead of a VBGpostcmd function, we can use an autocmd event:

   function! s:recordCall(...)
   " .....
   doautocmd User Vebugger_PostCmd
   endfunction
   
   " ........
   " registering an hook on the post-cmd event:
   autocmd User Vebugger_PostCmd call MyFunction()

3. You can't pass arguments to Vim's User events - but the last command data is already recorded in the current debugger dictionary!

If you don't mind, I'd rather implement this thing myself, since it requires some modification to the activation path of the commands(I don't want the plugin directory to hack the autocmd directory of the same plugin...). I'll try to get to it during the weekend.

[rdnetto]

Sure, that sounds fine. Autocmds are definitely the better approach to take, it just didn't occur to me to use them.
I'm fine with you implementing it - I'm more interested in having the feature than who writes the code. :P

[idanarye]

@rdnetto I've pushed it to develop. Most user commands(except for starting/killing the debugger and altering the breakpoints) now go through vebugger#userAction, which registers the action in the active debugger object and launches the Vebugger_PreUserAction and Vebugger_PostUserAction autocmd User events.

I've also added vebugger#repeatLastUserAction and :VBGrepeat that calls it.

Please check it out and see if there is anything you want to add/change. At any rate, it'll be a while before I make a new release - this is a breaking change which means bumping the major version, and I want to push some more big features(watchers, catching exceptions, moving up&down the backtrace) before I release version 2.0.

[rdnetto]

Overall it looks good, but there is one thing I'd like to change:
The try-catch blocks here mean that any errors in the user's autocmd hooks are silently discarded (which makes debugging them rather confusing). They don't seem to be necessary either - doautocmd works fine even if the user hasn't added a hook. I think just removing them would work fine.

[idanarye]

Well, the idea was that even if an event listener throws, the user action will still happen(because I'd like to avoid breaking the main functionality of the plugin just because some other plugin has errors...), but your point about it making the event listeners harder to debug is valid. I've changed it to use try...finally.

BTW - this has nothing to do with doautocmd when the user haven't added a hook - in that case Vim will print "No matching autocommands" either way(I have the NOP autocmd for that). What I'm afraid of is exceptions in Vebugger_PreUserAction preventing the user action from running...

[TamaMcGlinn]

This PR should be closed, the feature is implemented as far as is planned.