When inspecting an array you are unable to see the total number of child elements if it exceeds 32. (As is often the case in drupals render arrays).

I have checked my xdebug settings and the xdebug.var_display_max_children=128 but im happy to look anywhere else you'd like to confirm proper setup as well.

Test code I confirmed it with:

<?php
$test = array();
for($i=0;$i<100;$i++) {
  $test[] = $i;
}
count($test);

Actual result: array inspector shows 32 children
Expected result: Should show all 100

I am using vdebug on a PHP project, and sometimes I cannot set breakpoints any more. Restarting vim helps. I do not know what triggers this, initially I can set breakpoints but from some point onwards the following happens:

An error occured: <class 'vdebug.opts.OptionsError'>
Traceback (most recent call last):
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 111, in set_breakpoint
self.runner.set_breakpoint(args)
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 184, in set_breakpoint
bp = vdebug.breakpoint.Breakpoint.parse(self.ui,args)
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/breakpoint.py", line 107, in parse
file = ui.get_current_file()
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 76, in get_current_file
return vdebug.util.FilePath(vim.current.buffer.name)
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/util.py", line 13, in init
self.local = self._create_local(filename)
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/util.py", line 22, in _create_local
if vdebug.opts.Options.isset('remote_path'):
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/opts.py", line 41, in isset
inst = cls.inst()
File "/home/fiesh/.vim/bundle/vdebug/plugin/python/vdebug/opts.py", line 19, in inst
raise OptionsError, "No options have been set"
OptionsError: No options have been set

I don't think versioning the tags file is considered good practice, I have always seen it git-ignored, since the user (or usually a plugin, pathoged does it for me) is in charge of building it.
Versioning puts the burden of keeping it up to date upstream, which is usually not required, and a frail assumption.
For example right now I have this diff in the repo, I personally would git rm --cached it.

diff --git i/doc/tags w/doc/tags
index f9b3a74..545fc5f 100644
--- i/doc/tags
+++ w/doc/tags
@@ -14,6 +14,7 @@ VdebugCommands        Vdebug.txt      /*VdebugCommands*
 VdebugEval     Vdebug.txt      /*VdebugEval*
 VdebugEvalExpression   Vdebug.txt      /*VdebugEvalExpression*
 VdebugEvalHighlighted  Vdebug.txt      /*VdebugEvalHighlighted*
+VdebugEvalUnderCursor  Vdebug.txt      /*VdebugEvalUnderCursor*
 VdebugIDEKey   Vdebug.txt      /*VdebugIDEKey*
 VdebugInstallation     Vdebug.txt      /*VdebugInstallation*
 VdebugIntro    Vdebug.txt      /*VdebugIntro*

Hello,

I'm trying to use vdebug on python project who's inside virtual-env, and am getting this error from pydbgp when run from withing virtual-env.

Traceback (most recent call last):
File "./bin/pydbgp", line 71, in
import getopt
ImportError: No module named getopt

If pydbgp is run outside of the virtual-env of the project, the project specific packges installed in virtual-env are not found and pydbgp fails. When run from the same virtual-env as the project the above error is being raised.

pydbgp version information:
$ pydbgp --v
pydbgp Version 1.1.0 Revision #1 Change 118727

Version of Komodo remote debugger:
Komodo-PythonRemoteDebugging-7.1.3-74661-linux-x86_64.tar.gz

Although this may not be directly related to vdebug, it's related to usage of the tool. So any help or suggestions are welcome.

Name says it all. Here's the error:

Invalid file name '~/vdebug.log' for log file: [Errno 2] No such file or directory: '~/vdebug.log'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 33, in run
    self.handle_exception(e)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 234, in handle_exception
    self.handle_readable_error(e)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 205, in handle_readable_error
    self.runner.ui.error(str(e))
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 138, in error
    vdebug.log.Log(string,vdebug.log.Logger.ERROR)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/log.py", line 100, in __init__
    Log.log(string,level)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/log.py", line 105, in log
    l.log(string,level)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/log.py", line 90, in log
    self.__open()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/log.py", line 76, in __open
    %(self.filename,str(e)))
vdebug.log.LogError: Invalid file name '~/vdebug.log' for log file: [Errno 2] No such file or directory: '~/vdebug.log'

Hi Jon, thanks for vdebug — it's really friendly.

I faced with key bindings problem when I use gvim (in vim everything works great).

My gvim was built with gtk support. When I press it shows me dropdown menu instead of setting a breakpoint. Ok, not a problem — I remapped everything in my .vimrc:

let g:vdebug_keymap = {                                                                                             
            \    "run" : "<S-F5>",                                                                                                
            \    "run_to_cursor" : "<S-F9>",                                                                                      
            \    "step_over" : "<S-F2>",                                                                                          
            \    "step_into" : "<S-F3>",                                                                                          
            \    "step_out" : "<S-F4>",                                                                                           
            \    "close" : "<S-F6>",                                                                                              
            \    "detach" : "<S-F7>",                                                                                             
            \    "set_breakpoint" : "<S-F10>",                                                                                    
            \    "get_context" : "<S-F11>",                                                                                       
            \    "eval_under_cursor" : "<S-F12>",                                                                                 
            \}

Now when I press nothing is happening — no breakpoint and no menu dropdown. Gvim is just quiet.

Any suggestions?

P.S: Thanks again

This is an issue reported by email.

Watch window characters do not display correctly on Windows - instead of the correct Unicode characters, garbage is displayed.

If a visual eval is attempted when a debugging session hasn't been started, an error is thrown:

- [ERROR] {Thu 28 2013 13:42:30} An error occured: <type 'exceptions.AttributeError'>
Traceback (most recent call last):
  File "/home/jon/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 103, in handle_visual_eval
    return self.event_dispatcher.visual_eval()
  File "/home/jon/.vim/bundle/vdebug/plugin/python/vdebug/event.py", line 13, in visual_eval
    return event.execute(self.runner)
  File "/home/jon/.vim/bundle/vdebug/plugin/python/vdebug/event.py", line 61, in execute
    runner.eval(selection)
  File "/home/jon/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 207, in eval
    context_res = self.api.eval(code)
AttributeError: 'NoneType' object has no attribute 'eval'

Having to press F5 to start listening (and nothing else) for 20 seconds and then refresh the page is a bit of a nuisance, and actually can be very frustrating. Consider this: I have a server-side API server based on PHP and a javascript client that interacts with the API server on the user's behalf. Understandably, the javascript client makes a lot of AJAX requests to the API server. Unless I have superhuman timing (or introduce delays/triggers all over my code) I can't catch the right request to debug - furthermore, while I'm debugging, any other requests are going to go straight through to the server. The end result is that, usually, the first request that is made gets debugged and the rest just slip by.

https://github.com/brookhong/DBGPavim has addressed this issue; I don't know how it works in the back, but this is what the user sees: in the bottom-right, there is a bit of information about the state of the debugger; whether it is idle, listening, or connected (plus how many connections are pending). F5 toggles the state of the debugger between listening and idle. While listening, the debugger does not interrupt the usability of vim at all; only once a connection is captured does debugging start. All connections are captured and queued so you get through them all.

I don't know how much work would be involved in implementing this, but it would absolutely make this plugin for me. If it is at all possible, I want it. Please. I'll give it a shot myself if you rather wouldn't, just let me know.

Hi, this looks awesome!

Just tested it a little, and wanted to give a short feedback on first impression.

When stopping at a breakpoint, I want to quickly see what's in a variable. With previous debugger client I could just hit F12 and pop, the variable content gets displayed. Is this possible? Now I have to browse the list of variables (sometimes that can be a lot, depending on file and local scope), seems counter-intuitive.

Also, when expanding the variable tree node with enter, it would be super nice to also close the node again with enter!

Keep up the good work, I really appreciate the effort into making a better debugger! :-)

If you've changed the default keymappings for starting/stopping Vdebug, these changes aren't reflected in the status window when debugging.

When I run the debugger, the code buffer is empty. While stepping through code, I can see variables update in the DebuggerWatch buffer, but the code buffer remains empty.

Additionally, execution doesn't stop at breakpoints, even on a trivial script, though xdebug_break() works.

I see the same behaviour after disabling all other plugins.

Vdebug 1.3.2, Python 2.7, Xdebug v2.1.0, Vim 7.3.843.

Just a wild (maybe useless) idea: would it be possible to add a 'continuous mode'? This would be a mode where VDebug would automatically restart to listen (with a large enough timeout) after a request has ended. That would allow one to setup some breakpoints, start the debugger in Vim, and click through the php project until the page is reached which will trigger the breakpoints.
Now most of the times I set my breakpoints, start clicking around to reach the correct page, and before the final click need to remember to, at that moment, start the debugger in vim before continuing.

(obviously this is most useful if you have configured XDebug to automatically open a debug session on the server)

Instead of setting options with let g:vdebug_options['option_name'] = 'this', it would be much more user friendly to be able to set them with a command like:

:VdebugOpt server 127.0.0.1
:VdebugOpt debug_file /tmp/vdebug.log

Option names can then be autocompleted and option values can be validated.

If you start the debugger from a buffer with unsaved changes and breakpoints, it fails to start entirely and you get this error:

E37: No write since last change (add ! to override)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 31, in run
    self.runner.run()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 137, in run
    self.open()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 42, in open
    self.ui.open()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 31, in open
    vim.command('silent tabnew ' + cur_buf_name)
vim.error

After that, any attempt to start the debugger from anywhere - whether or not there are still unsaved changes - will produce this error:

An error occured: <type 'exceptions.AttributeError'>
Traceback (most recent call last):
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 31, in run
    self.runner.run()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 140, in run
    self.ui.statuswin.set_status("running")
AttributeError: 'NoneType' object has no attribute 'set_status'

Restarting vim allows you to use the debugger again.

I can see the need for the user to write their changes before debugging can begin, but it should be handled better. Futhermore, after exploding the debugger like this, I suffer from issue #43 again until I reboot (restarting apache is insufficient and I'm not using php-fpm). I fail to recognise that my app is never reaching the code I'm looking at, sorry - disregard the bit about issue #43

When I put breakpoint on empty line debug process unexpectedly stopped (I'm debugging PHP application with xdebug).

I see 2 solutions:

1. Disable ability to create breakpoint on empty line
2. Automatically move breakpoit to next not-empty line.

Thanks

Hi

I hava installed your plugin and i create a bp in my code, then I run F5 but it stops before the bp I created..I'm quite newbie to debuggint but I expected the debugger stops on the breakpoint I created..

This is my code:

<?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
  * wp-blog-header.php which does and tells WordPress to load the theme.
  *
  * @package WordPress
  */

 /**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
 define('WP_USE_THEMES', true);  // it stops here

 $jander = 23; 

 echo "hola";  //here it is the breakpoint!!!!!!!!!!!!!!!!!!!!!!

 /** Loads the WordPress Environment and Template */
 require('./wp-blog-header.php');

Hello,

I am using vdebug with vim and think it is really great. However whenever I stop debugging with F6 I notice that there are a whole bunch of [No Name] buffers that show up when I do a :ls command.
When I try to use :bd on them they don't get removed and I have to cycle through them when I am using :bn and :bp do you know of anything I could do to figure out why they are being created?

Here is my :ls output after running vdebug a couple times.

1 %a + "portfolio.php" line 27
2 #a "[No Name]" line 1
6 a "[No Name]" line 1
10 h "includes/functions.php" line 78
11 h "includes/header.php" line 26
12 a "[No Name]" line 1
16 h- "[Vundle] Installer" line 19

After adding a breakpoint and walking through the debugger I am unable to remove the breakpoint (f10) after i exit debugging with f6.

I am able to add and remove it with toggle f10 until I actuality use it as a stopping point.

Tested with master and dev branches.

Hi,
I think I'm doing something wrong with vdebug's windows/tabs.
My use case is the following:

• I start debugging and vdebug opens a new tab with all its windows.
• Then I finish debugging and I :tabclose vdebug's tab.
• Then I maybe want to start debugging again, so I press g:vdebug_keymap['run'] (which is F8 for me) and I get the following error.

"DebuggerStack" [New File]
E37: No write since last change (add ! to override)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/start_vdebug.py", line 30, in run
    self.runner.run()
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/runner.py", line 135, in run
    self.open()
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/runner.py", line 63, in open
    self.refresh(status)
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/runner.py", line 88, in refresh
    stack_res = self.update_stack()
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/runner.py", line 268, in update_stack
    self.ui.stackwin.accept_renderer(renderer)
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/ui/vimui.py", line 300, in accept_renderer
    self.write(renderer.render())
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/ui/vimui.py", line 370, in write
    Window.write(self, msg, after="normal gg")
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/ui/vimui.py", line 219, in write
    self.create()
  File "/home/grota/rcfiles/vim/dotvim/bundle/joonty_vdebug/plugin/python/vdebug/ui/vimui.py", line 273, in create
    vim.command('silent ' + self.open_cmd + ' ' + self.name)
vim.error
Press ENTER or type command to continue

I think I'm operating on vdebug's tab/windows incorrectly. What's the right way to fulfill the use case described above?

Related to the question above, say I close DebuggerWatch window. How can I reopen it?

Again, may be related to the questions above, say I :VdebugEval 2+2. The contents of the DebuggerWatch window get overwritten, how do I get back to the previous content?

Scenario:

• I set a breakpoint / some breakpoints
• I start debugging
• I run my script
• I get the connection, debug session starts (yay!)
• Breakpoints completely ignored
• Upon ending debug session, breakpoints cannot be unset
• :BreakpointWindow throws a big fat error then shows an empty list
• Have to quit vim completely; "zombie" breakpoints persist even if buffers reloaded

I am using Vim 7.3 and have ALL THE FEATURES. All of them. I'm using up-to-date versions of PHP and Xdebug. This is the error I mentioned:

An error occured: <type 'exceptions.TypeError'>
Traceback (most recent call last):
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 127, in toggle_breakpoint_window
    return self.runner.toggle_breakpoint_window()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 122, in toggle_breakpoint_window
    self.ui.breakpointwin.create()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 311, in create
    self.on_create()
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 346, in on_create
    self.add_breakpoint(bp)
  File "/home/qstrahl/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 354, in add_breakpoint
    str += "%s:%i" %(breakpoint.file,breakpoint.line)
TypeError: %d format: a number is required, not str

If it means anything to you, the debugging plugins I used previously (and recklessly abandoned at the first sight of VDebug) worked without any such problems. I haven't changed anything since then except remove that plugin completely and add Vdebug. I'm using Pathogen. I'm managing my bundles as git submodules (my .vim directory is a git repo). I'm not sure what further information would be helpful. I'm not sure this information will be helpful. I'm not sure of anything anymore.

Expanding tree nodes works initially but if you eval a variable and then try and expand a closed node you get the message 'can not get property'. You can close already open nodes - however you can not open them again once closed.

Hello I am trying to debug a PHP script and I set a breakpoint and hit to start debugging and it did what is illustrated in the screenshot and then gave this error message.

Traceback (most recent call last):
File "", line 1, in
File "/Users/gdance/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 31, in run
self.runner.run()
File "/Users/gdance/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 137, in run
self.open()
File "/Users/gdance/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 42, in open
self.ui.open()
File "/Users/gdance/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 28, in open
vim.command('silent tabnew ' + cur_buf_name)

Sometimes, after starting the debugger, closing and restarting, the source panel appears as an extra horizontal split at the top of the window. The panel should be on the left side of a vertical split, but another file is shown in this buffer.

If the extra panels is closed, tepping over/in/etc. causes the panel to reopen.

Checking multi-byte support in Vim (for swapping between ASCII/Unicode markers in the watch window) was broken due to:

if has("multibyte") == 0

which should be:

if has("multi_byte") == 0

Add features for remote path mapping:

• Allow regular expressions for remote path mapping
• GUI style interface for managing multiple path maps, as Vim dictionary is cumbersome
• Remove path maps from options dictionary, have separate dictionary

Heya,

So I'm using Vdebug for XDebug. Let's say I have a stack trace and went up a trace. How do I evaluate the variables on that trace? Not entirely sure if my question makes sense. :D

Now vdebug starts only listening process and process to debug should be started manually outside Vim.
For now I use following code in my vimrc to automate the process:

    function! Debug(url)
        let url = a:url
        " add 'http://' if it is not in url
        let http_pos = stridx(url, 'http')
        if http_pos != 0
            let url = 'http://'.url
        endif
        " add 'vim_debug' IDE key to url, this IDE key is also set in vdebug options
        let q_pos = stridx(url, '?')
        if q_pos == -1
            let url = url.'?XDEBUG_SESSION_START=vim_debug'
        else
            let url = url.'&XDEBUG_SESSION_START=vim_debug'
        endif
        " launch browser
        call OpenBrowser(url)
         " start debugging
        python debugger.run()
    endfunction
    command! -nargs=1 Debug call Debug('<args>')

This command allow to launch browser via OpenBrowser plugin and then start vdebug.
I use it like this:

: Debug http://myhost.com/xxx.php

Another one to debug currently edited python script:

    function! DebugPy(...)
        let str_args = join(a:000, ' ')
        " command to launch - uses local path to pydbgp, probably this can be done in a better way
        let last_cmd = '!python -S ~/pydbgp/bin/pydbgp -d localhost:9000 -k vim_debug ' . str_args
        " save last used args, command and its results to files (for debugging of this function)
        execute 'silent !echo "' . str_args . '" > ~/vim.last.arg.txt &'
        execute 'silent !echo "' . last_cmd . '" > ~/vim.last.cmd.txt &'
        " launch command in backgound
        execute 'silent ' . last_cmd . ' > ~/vim.last.out.txt 2> ~/vim.last.err.txt &'
        " start debugging
        python debugger.run()
    endfunction
    command! -nargs=* DebugPy call DebugPy('% <args>')

Now I can do this:

: DebugPy

And debug current python file.

Probably the same can be done in a better way inside the python code and maybe not only for php/python, but for other supported languages as well.

Also another python-based plugin for debugging, vim-debug, can do this

When I started vdebug, the mappings don't seem to work, however when I type

:nmap

I see

:python debugger.run()

like you would expect. As it turns out, I think there is a simple fix; my setup has some mappings tied to for some autocomplete pluggins, and this is messing it up. I think the solution is to use nnoremap instead of nmap. When I manually set the mappings using nnoremap, everything works great.

Thanks for this very nice plugin!

Taken from an email from Ben Hicks:

Hi,
i don't know if you are aware of this and i hope this is the right channel to send you this information, when trying to cancel a waiting connection i get a warning from python:

.vim/plugin/python/vdebug/util.py:161: DeprecationWarning: catching of string exceptions is deprecated except vim.error:

Versions i used:
Vdebug: 1.3.1
Python: 2.6.5

kind regards,

Ben Hicks

This is an issue reported by email.

Watch window variables do not respond to expanding, by pressing return or double clicking.

Hi there,

I suspect this might be a python issue, but since there are no more specific requirements listed than that...

I get this error starting vim - any pointers welcome:

Error detected while processing /var/home/martinr/.vim/bundle/vdebug/plugin/vdebug.vim:
line 38:
Traceback (most recent call last):
File "", line 1, in ?
File "/var/home/martinr/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 10, in ?
import vdebug.runner
File "/var/home/martinr/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 3, in ?
import vdebug.dbgp
File "/var/home/martinr/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 576
self.has_children = True if children > 0 else False
^
SyntaxError: invalid syntax
line 83:
Traceback (most recent call last):
File "", line 1, in ?
NameError: name 'DebuggerInterface' is not defined
Press ENTER or type command to continue

Could you define the highlights for DbgBreakPt and DbgCurrent with the 'default' keyword so they are only defined if they are not already defined in the colorscheme?

hi default DbgCurrent term=reverse ctermfg=White ctermbg=Red gui=reverse
hi default DbgBreakPt term=reverse ctermfg=White ctermbg=Green gui=reverse

thanks!

This is great, and I'd like to suggest an improvement so one doesn't have to use two terminals to debug scripts (or maybe I'm just doing it wrong*):

How about having F5 run the debugger automatically depending on the filetype of the current script? This could be a variable, so people can tell Vdebug the full command to be executed per filetype, and maybe have some defaults already configured. stdout/stderr, eg. anything from print statements, could be captured and shown in a different window or windows.

*I have two terminals open. In one, I run vim with no other arguments. I then press F5 in it, and Vdebug waits for a connection. In the other terminal, I run, "perl -d script.pl". In the first terminal, Vdebug notices the connection and I can debug script.pl in it. Is that how it's supposed to work?

It seems that Vdebug sometimes seems to ignore breakpoints at certain lines of code. Although this might be an XDebug problem as well...

I had the following situation (Drupal project, PHP 5.3 on Ubuntu server with XDebug setup for remote debugging) ((added the comments to clarify the breakpoints):

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  dpm($form_id); // <-- breakpoint, does not break
}

I set a breakpoint on the single line of code inside that function (with F10), start the debugger and connect it to the loading webpage. It first breaks at the first line of the Drupal bootstrap code, but when I then press F5 is completely runs the rest of the script without stopping at the breakpoint.

Then I changed my function like this:

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  dpm($form_id); // <-- breakpoint, does not break
  throw new Exception('..'); // <-- breakpoint, does break
}

and put 2 breakpoints in the function (one on each line) and start the debugger again. Again the debugger starts at the first line of the Drupal bootstrap. But when I press F5 in that case, it stops at the line which throws the Exception.

And while I was writing this issue i tested a bit more. If i put a breakpoint on the closing } of the first version of the function, it also correctly stops at that breakpoint. This seems a bit strange as that line doesn't really contain any real code (IIRC it would be impossible to put a breakpoint at such a line in Visual Studio.NET for example). To clarify:

function mymodule_form_alter(&$form, &$form_state, $form_id) {
  dpm($form_id);
} // <-- breakpoint, does break

Thx for any help!

The bug replicates after you set a line breakpoint and finish one debug session. At this time, you cannot de-highlight the breakpoint anymore, plus when typing :BreakPointWindow will lead to the following errors:
An error occured: <type 'exceptions.TypeError'>
Traceback (most recent call last):
File "/home/joe/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 127, in toggle_breakpoint_window
return self.runner.toggle_breakpoint_window()
File "/home/joe/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 122, in toggle_breakpoint_window
self.ui.breakpointwin.create()
File "/home/joe/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 311, in create
self.on_create()
File "/home/joe/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 346, in on_create
self.add_breakpoint(bp)
File "/home/joe/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 354, in add_breakpoint
str += "%s:%i" %(breakpoint.file,breakpoint.line)
TypeError: %d format: a number is required, not str

P.S.: It would be nice if there is any indicator that shows whenever the conditional breakpoint is set. it is different from other breakpoints since it's specific to a single line.

VdebugEval error for ruby!

Thanks for this great tool! it looks really nice!

I have done the changes from the gist as suggested in the help. Now everything works for python.
For ruby, I do not have problem to change context in the watch window. But the VdebugEval command
gives the following errors:

- [ERROR] {Thu 16 2012 19:36:39} An error occured: <class 'vdebug.dbgp.DBGPError'>
Traceback (most recent call last):
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 95, in handle_eval
    return self.runner.eval(args)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 199, in eval
    context_res = self.api.eval(code)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 274, in eval
    return self.send_cmd('eval',args,EvalResponse)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 222, in send_cmd
    return res_cls(msg,cmd,args,self)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 116, in __init__
    raise e
    DBGPError: ('Command eval not recognized\n', '4')


    - [ERROR] {Thu 16 2012 19:38:05} An error occured: <class 'vdebug.dbgp.DBGPError'>
    Traceback (most recent call last):
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 95, in handle_eval
    return self.runner.eval(args)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 199, in eval
    context_res = self.api.eval(code)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 274, in eval
    return self.send_cmd('eval',args,EvalResponse)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 222, in send_cmd
    return res_cls(msg,cmd,args,self)
    File "/Users/zhaocai/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 116, in __init__
    raise e
    DBGPError: ('Command eval not recognized\n', '4')


    ```

Scenario:

• I am in tab1 with some folds
• Start debugging
• Folds have been forgotten

Depending on the value of 'foldmethod', the problem looks different (but probably isn't); for manual folds, all folds are lost (!!!). For computed folds (all other foldmethods), all folds revert to their default state (closed).

Github says F9 makes the debugger run to the cursor. The help files in one place say that F1 does this, and in another say F10 does this. Unable to test if F9 really does this because my debugging is broken due to: #43

I'm getting strange error.

Steps to reproduce:

1. F10 to create breakpoint
2. F5 to start debugging
3. Update my browser to start process
4. Everithing were ok
5. When I pressed F2 to proceed debugging I got error

An error occured: <type 'exceptions.UnicodeDecodeError'>
Traceback (most recent call last):
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 47, in step_over
self.runner.step_over()
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 152, in step_over
self.refresh(res)
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 101, in refresh
self.get_context(0)
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 112, in get_context
self.ui.watchwin.accept_renderer(rend)
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 332, in accept_renderer
self.write(renderer.render())
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 484, in render
res += self.__render_property(prop,next_prop,final,indent)
File "/home/kuzma/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 504, in __render_property
'type':p.type_and_size(),'value':p.value}
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3: ordinal not in range(128)

Screenshot: http://i.imagebanana.com/img/59m5hea4/Selection_184.png

After stopping the debugger any previously defined mappings that have been overwritten by vdebug should get restored.

See 38d0506 , where the initial dynamic mapping had been introduced.

map() should query the current mapping and unmap should restore them.

When stepping through the code, the visible part of the DebuggerWatch window should be constant. Because when I have scrolled down to keep a particular variable in my eye, I don't want to scroll again after ever step of the Debugger.

Besides, expanded nodes should stay expanded.

The VdebugEval command does not handle escaping of <args> properly.

command! -nargs=? VdebugEval python debugger.handle_eval('<args>')

VdebugEval echo 'foo' results in:

  File "<string>", line 1
    debugger.handle_eval('echo 'foo'')
                              ^
SyntaxError: invalid syntax

The same also applies to the Breakpoint commands, although they are normally not called like that.

I noticed that doc/tags is included in the repository (because running ":Helptags" apparently added a new line about "VdebugEvalUnderCursor" and the file appeared up as modified).

It is not useful in general to have these files in the repository.

Another usage question, a separate one so that i don't mix things with #30
My current (temporary) config is as follows:

let g:vdebug_keymap = {
\    "run" : "<F8>",
\    "set_breakpoint" : "<leader><F10>",
\    "run_to_cursor" : "<leader><F1>",
\    "step_over" : "<F6>",
\    "step_into" : "<F7>",
\    "step_out" : "<leader><F4>",
\    "close" : "<leader><F6>",
\    "detach" : "<leader><F7>",
\    "get_context" : "<leader><F8>",
\    "eval_under_cursor" : "<leader><F12>",
\}
let g:vdebug_options= {
....
\    "on_close" : 'detach',
....
\}

I start debugging, I'm on a brekpoint and I press <leader>F7. The log window tells me:

- [Info] {Tue 08 2013 23:02:47} Detaching the debugger

- [Debug] {Tue 08 2013 23:02:47} Command: detach -i 6

- [Debug] {Tue 08 2013 23:02:47} Response: <?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="detach" transaction_id="6" status="stopping" reason="ok"></response>

But, oddly enough, the browser is still waiting for things to end on the debugger side. When I finally issue a close with <leader>F6 the browser finally stops waiting but receives nothing:
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data

The other strange thing is that I have on_close set to detach, and during a debug session, when I type <leader> F6 the session gets detached correctly meaning that everything ends correctly on the debugger side and the browser receives all the http packet(s) that I except it to receive.

If you modify a file by adding or removing lines, the breakpoints do not work correctly.

Steps to reproduce

Edit a file
Set a breakpoint at line 100
Add two extra lines above line 100 - Note that the placed "sign" for the breakpoint moves down
Place the cursor on the line with the breakpoint marker and attempt to remove it

In BreakpointWindow the breakpoint is still listed at line 100
However if you run ":sign place" then it is correctly listed at line 102.

A possible solution would be to parse the results of ":sign place" and use the ids to map the correct line number

Hi joonty, thanks for your great plugin.
I have some trouble in keymap conflicting.
I think the default keymap <F1> should be changed. Because On many platform, is about ask help from os.

Hi, Joonty.
Thanks for your great job. I like your plugin very much.
It seems you limit the string length to '1024', and the string length can be only displayed with a limit length, though I set 'xdebug.var_display_max_data=-1' on xdebug.ini to enable the string length to unlimit.
And I notice you provide the function 'def feature_set(self,name,value):' in dbgp.py. But, there is no interface to invoke the function by GUI, though I can do it by python command line.
I think it will be better to enable the unlimit string length by adding the following codes in dbgp.py file.

1. before the end of function 'def eval(self,code):'
   self.feature_set('max_data', 102400) --- this line is added, I set the value as 102400, if the user press 'F12' to eval the value, it is set large enough to display.
   return self.send_cmd('eval',args,EvalResponse)
2. before the end of function 'def context_get(self,context = 0):'
   self.feature_set('max_data', 1024) --- this line is added, pressing 'F11', to set the length back to its origin value.
   return self.send_cmd('context_get',
   '-c %i' % int(context),
   ContextGetResponse)

-Thanks, Jimmy.

Seems to be an bug on Python 2.7.3. Here is the output after pressing :

An error occured: <type 'exceptions.SystemError'>
Traceback (most recent call last):
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 31, in run
    self.runner.run()
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 137, in run
    self.open()
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 40, in open
    vdebug.opts.Options.get('timeout',int))
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 253, in listen
    self.api = vdebug.dbgp.Api(connection)
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 195, in __init__
    self.conn.open()
  File "/mnt/md0/Projects/Configs/vim-config/.vim/bundle/vdebug/plugin/python/vdebug/dbgp.py", line 410, in open
    print 'Waiting for a connection (Ctrl-C to cancel, this message will self-destruct in ',self.timeout,' seconds...)'
SystemError: NULL result without error in PyObject_Call 

$ vim --version

vim --version

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 29 2012 11:33:02)
Inklusive der Korrekturen: 1-645
Übersetzt von <[email protected]>
Riesige Version ohne GUI. Ein- (+) oder ausschließlich (-) der Eigenschaften:
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs 
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path 
+find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv 
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent 
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
+mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse 
+mouse_xterm +mouse_urxvt +mouse_sgr +multi_byte +multi_lang -mzscheme 
+netbeans_intg +path_extra +perl +persistent_undo +postscript +printer +profile
 +python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs 
+smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
 -xterm_clipboard -xterm_save 
          System-vimrc-Datei: "$VIM/vimrc"
        Benutzer-vimrc-Datei: "$HOME/.vimrc"
         Benutzer-exrc-Datei: "$HOME/.exrc"
     Voreinstellung für $VIM: "/usr/share/vim"
Übersetzt: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -I/usr/local/include  -O2 -fPIC -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linken: gcc   -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE   -L/usr/local/lib -Wl,--as-needed -o vim       -lm -lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl    -Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector  -L/usr/lib64/perl5/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic

python -v

# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/lib64/python2.7/site.pyc matches /usr/lib64/python2.7/site.py
import site # precompiled from /usr/lib64/python2.7/site.pyc
# /usr/lib64/python2.7/os.pyc matches /usr/lib64/python2.7/os.py
import os # precompiled from /usr/lib64/python2.7/os.pyc
import errno # builtin
import posix # builtin
# /usr/lib64/python2.7/posixpath.pyc matches /usr/lib64/python2.7/posixpath.py
import posixpath # precompiled from /usr/lib64/python2.7/posixpath.pyc
# /usr/lib64/python2.7/stat.pyc matches /usr/lib64/python2.7/stat.py
import stat # precompiled from /usr/lib64/python2.7/stat.pyc
# /usr/lib64/python2.7/genericpath.pyc matches /usr/lib64/python2.7/genericpath.py
import genericpath # precompiled from /usr/lib64/python2.7/genericpath.pyc
# /usr/lib64/python2.7/warnings.pyc matches /usr/lib64/python2.7/warnings.py
import warnings # precompiled from /usr/lib64/python2.7/warnings.pyc
# /usr/lib64/python2.7/linecache.pyc matches /usr/lib64/python2.7/linecache.py
import linecache # precompiled from /usr/lib64/python2.7/linecache.pyc
# /usr/lib64/python2.7/types.pyc matches /usr/lib64/python2.7/types.py
import types # precompiled from /usr/lib64/python2.7/types.pyc
# /usr/lib64/python2.7/UserDict.pyc matches /usr/lib64/python2.7/UserDict.py
import UserDict # precompiled from /usr/lib64/python2.7/UserDict.pyc
# /usr/lib64/python2.7/_abcoll.pyc matches /usr/lib64/python2.7/_abcoll.py
import _abcoll # precompiled from /usr/lib64/python2.7/_abcoll.pyc
# /usr/lib64/python2.7/abc.pyc matches /usr/lib64/python2.7/abc.py
import abc # precompiled from /usr/lib64/python2.7/abc.pyc
# /usr/lib64/python2.7/_weakrefset.pyc matches /usr/lib64/python2.7/_weakrefset.py
import _weakrefset # precompiled from /usr/lib64/python2.7/_weakrefset.pyc
import _weakref # builtin
# /usr/lib64/python2.7/copy_reg.pyc matches /usr/lib64/python2.7/copy_reg.py
import copy_reg # precompiled from /usr/lib64/python2.7/copy_reg.pyc
# /usr/lib64/python2.7/traceback.pyc matches /usr/lib64/python2.7/traceback.py
import traceback # precompiled from /usr/lib64/python2.7/traceback.pyc
# /usr/lib64/python2.7/sysconfig.pyc matches /usr/lib64/python2.7/sysconfig.py
import sysconfig # precompiled from /usr/lib64/python2.7/sysconfig.pyc
# /usr/lib64/python2.7/re.pyc matches /usr/lib64/python2.7/re.py
import re # precompiled from /usr/lib64/python2.7/re.pyc
# /usr/lib64/python2.7/sre_compile.pyc matches /usr/lib64/python2.7/sre_compile.py
import sre_compile # precompiled from /usr/lib64/python2.7/sre_compile.pyc
import _sre # builtin
# /usr/lib64/python2.7/sre_parse.pyc matches /usr/lib64/python2.7/sre_parse.py
import sre_parse # precompiled from /usr/lib64/python2.7/sre_parse.pyc
# /usr/lib64/python2.7/sre_constants.pyc matches /usr/lib64/python2.7/sre_constants.py
import sre_constants # precompiled from /usr/lib64/python2.7/sre_constants.pyc
import encodings # directory /usr/lib64/python2.7/encodings
# /usr/lib64/python2.7/encodings/__init__.pyc matches /usr/lib64/python2.7/encodings/__init__.py
import encodings # precompiled from /usr/lib64/python2.7/encodings/__init__.pyc
# /usr/lib64/python2.7/codecs.pyc matches /usr/lib64/python2.7/codecs.py
import codecs # precompiled from /usr/lib64/python2.7/codecs.pyc
import _codecs # builtin
# /usr/lib64/python2.7/encodings/aliases.pyc matches /usr/lib64/python2.7/encodings/aliases.py
import encodings.aliases # precompiled from /usr/lib64/python2.7/encodings/aliases.pyc
# /usr/lib64/python2.7/encodings/utf_8.pyc matches /usr/lib64/python2.7/encodings/utf_8.py
import encodings.utf_8 # precompiled from /usr/lib64/python2.7/encodings/utf_8.pyc
Python 2.7.3 (default, Jul  3 2012, 19:58:39) 
[GCC 4.7.1] on linux2

Cant figure it out where the problem comes from. Testet the same on an older
System, with Python 2.6.6, and can't encounter these problems.

How can I help you to improve this?

Hi,

when i close the debugger tab (F6 F6), the active tab becomes the one that was on the right of the file that I was before running the debug.

Ok, thats the default behaviour in vim when you close a tab, but I think this is not desiderable in this case.. What's your opinion?

Javi