Question about remote path mapping

[progga]

This is more of a support question rather than a bug report. I am trying to configure path mapping without success. The README has not helped much either :( My "remote" environment runs as a Virtualbox VM and shares files over NFS. So "/vagrant" of the remote environment is available as "/home/foo/vm/" in the local environment where I am running gedit. I have dropped a PHP file inside /vagrant and trying to debug it, but gedit seem to be ignoring it. While setting up path mapping, I have used "file:///vagrant/" as the remote path and "file:///home/foo/vm/" as the local path. Is this the right way to set it?

Debugging local PHP files is working okay. I have also ran netcat on port 9000 of the local machine and saw xdebug's XML snippets pouring in from the remote machine. So xdebug seem to be properly configured in the remote machine.

The profile file from /home/foo/.local/share/gedit/addiks/xdebug/debug-profiles/default currently looks like this:
{'dbgp_ide_key': 'GEDIT', 'port': 9000.0, 'dbgp_active': False, 'dbgp_host': 'localhost', 'dbgp_port': 9001.0, 'url': ''}

[addiks]

There are a couple of things that can be wrong here. Have you tried removing "file://" from the path's in the mapping? They should not be needed (and they may even cause the problems, at least i have never seen them there.). When looking at the xdebug XML messages you should also see the file-path's that gedit tries to register as breakpoints at the start of a session/process, is the mapping applied correctly on these path's? Have you set breakpoints in a line that contains php-code? (PHP cannot break in lines that do not contain an expression for example)

[progga]

After seeing your previous message, I have removed "file://" from the mapping paths although this has not changed anything :( So now the paths look like /home/foo/vm/ for local and /vagrant/ for remote. I have captured some packets using tcpdump and I can see gedit sending commands like these for breakpoints: breakpoint_set -i 19 -t line -f file:///home/foo/test.php -n 4

[addiks]

The file is in "/home/foo/test.php" and the mapping is for "/home/foo/vm/"? The PHP file should be inside the mapping. Is that the file you are trying to debug? If not, can you please show me a line for the file you are actually trying to debug? This plugin always sends all breakpoints it knows about to the server because it does not know which are relevant and which are not, so do not get confused by looking at a breakpoint-command that does not matter. Maybe it is easier to understand if you remove all unrelated breakpoints.

[progga]

I seem to have spotted the problem. First of all, even though I have not asked PHP to send any IDE key, it was sending one anyway. PHP has picked up "vagrant" as the IDE key. So first I had to update the debugger profile to use "vagrant" instead of "GEDIT". But the DebugSession class was still not using the mapping between remote and local files, so I made a minor change to its code and now I can debug both remote and local files from gedit. I have attached the patch file -
breakpoint-diff-issue-11.txt

[addiks]

I have just applied your patch and pushed it as a new revision. Please confirm that this new version is working for you.

[progga]

Sorry for the delay :( I will test it and get back to you within 2 days.

[addiks]

No need to hurry, i just don't like issues that stay open for month's without any reply. :)

[progga]

I can confirm that your latest change is working. Thanks a lot :-)

I have been using the gedit debugger heavily on Drupal for the last few days and I will take this opportunity to list two observations regarding user experience:

• Drupal has nearly 50 or so PHP constants. The debugger window lists local variables, global variables, and constants in one place. This makes it slightly difficult to find the variables I am after. If there were three separate panels/tabs for local variables, global variable, and constants, debugging experience will be slightly better.
• If I resize the debugging window and then close gedit, the size is lost when the debugging window is used the next time. In other words, Gedit itself retains its changed sizes between sessions, but not the debugging window.

Neither are major issues, but I thought I will keep you informed :)

[addiks]

I have opened two new issues (#12 & #13 ) for your ideas and how i would implement them. Maybe you want to comment on that before i begin working on it. I will not begin working on that for a while as i am currently quite busy with stuff for my work and also i want to implement a new feature for one of my other plugins first. However you are free to implement either yourself if you don't want to wait, i would welcome more people working on these plugins. :)

[progga]

Thanks for opening #12 and #13 :) I will see if I can contribute given my lack of knowledge of GEdit's plugin system. But I will give it a try.