Allow for persistent code evaluation in the watch window.

[benjifisher]

After :VdebugEval! expression, continue to evaluate expression in the watch window after running through the code. Clear with :VdebugEval!.

Here is my use case. I set a breakpoint, and the watch window is filled with so many variables that I have to scroll to see the one I want. So I do :VdebugEval array($myvar->property17, $myvar->property34). I run the code, and the same local variables fill the watch window. I know I can use @:, to repeat the :Vdebug command, but I want to save a few keystrokes.

This patch provides a :Vdebug! variant. After :Vdebug! expression, the watch window will continue showing expression as I step through the code or run to a breakpoint. I can use <F11> or :python debugger.get_context() to get the usual display, but expression will return if I run the code again. To return to the usual behavior, use :Vdebug! (with no expression argument).

If you like this idea, then I will complete it by adding tests and documentation. (I have not looked at the tests yet, but I think I can figure out how to do it.)

I know vim pretty well, but I am a novice at python, so I will be grateful for any advice or (constructive) criticism.

[joonty]

Sorry it's taken so long for me to get round to this.

I really like the succinctness of this! Someone else implemented something similar, which is the VdebugTrace command: this essentially does an eval and watches the same term as the debugger steps through. However, it's a bit different as it's a whole new command and opens a separate window. You can try it on the dev branch currently, but it's going into the next release.

However, I'm not convinced that it means we should throw away your PR - I don't see any harm in having the two routes to evaluating expressions, especially as some people would prefer not to have another window opened to trace an expression (and some people would).

What do you think?

Thanks again, and the Python code looks good :)

[benjifisher]

No need to apologize. My own projects are equally in need of attention.

Looking at my first comment, I think I wrote :Vdebug a couple of times when I meant :VdebugEval.

Some years ago, on the vim mailing list (or maybe vim-dev) I pointed out that the stated design goals did not explain why vim should have so many options. Bram's response was to add a goal:

VIM IS... FLEXIBLE                  *design-flexible*

Vim should make it easy for users to work in their preferred styles rather
than coercing its users into particular patterns of work.  This can be for
items with a large impact (e.g., the 'compatible' option) or for details.  The
defaults are carefully chosen such that most users will enjoy using Vim as it
is.  Commands and options can be used to adjust Vim to the desire of the user
and its environment.

I think that vim plugins should try to follow the same design goals as vim itself, which is my long-winded way of saying that I agree: let's give people both options for monitoring an expression.

I will try to carve out some time tomorrow to update the documentation, and maybe even add a test. If not then, maybe next weekend.

[benjifisher]

I see that :VdebugTrace is now in the master branch, not just dev, so I merged master into my branch.

I added some documentation for :VdebugEval!. I looked at the tests, but did not see any test suite that seemed appropriate for my changes. Adding a new test suite is too ambitious for me, so I will call it done with the additional documentation.

[joonty]

You convinced me! And this works really well.

Thanks very much, I'm going to release this with another fix today, for version 1.5.1.

[benjifisher]

I just noticed that this PR is still labeled "on hold" even though it has been merged.

[BlackIkeEagle]

@benjifisher It has a label 'on hold' but is closed because of the merge.

[joonty]

Sorted :)