This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 219726 - Edits made in PHP files in the include path are not reflected in code completion
Summary: Edits made in PHP files in the include path are not reflected in code completion
Status: NEW
Alias: None
Product: php
Classification: Unclassified
Component: Editor (show other bugs)
Version: 7.2
Hardware: Macintosh (x86) Mac OS X
: P3 normal (vote)
Assignee: Ondrej Brejla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-08 21:08 UTC by DanForys
Modified: 2012-10-09 09:26 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description DanForys 2012-10-08 21:08:36 UTC
Hello all. Not sure if this is by design - but it has been quietly irritating me for some time. I have only just managed to figure out reproduce steps.

Use case:
Large complex projects with many libraries (e.g. corporate code & Zend Framework). It is preferable to set a few, blanket include paths for all projects.

Issue:
If a file happens to appear in the include path, edits made to the file will not be available when using code completion. This includes properties and methods.

Reproduce steps:
- Create a new PHP project with no include path.
- Create a new PHP class file
- In the class, set a property like "const TEST1 = 'test1';"
- Create a method, write code to echo "self::TEST1" - note that code completion works.
- Add an include path to the folder *above* this test project
- Add a new property to the same class "const TEST2 = 'test2';"
- Write code to echo new property, note that code completion does not pick up the new property.

I assume from this behaviour that the code completion is resolved to the include path's version of the file before it was edited. Closing and reopening the file results in the new properties and methods appearing in code completion as expected.

It would be awesome if the code completion engine could be made slightly smarter to figure out that the edited file and the include path file are one and the same. I have very large projects and manually setting up the requisite include paths is a bit of a pain otherwise. Many thanks!
Comment 1 Ondrej Brejla 2012-10-09 06:48:30 UTC
Not sure if I understand it properly. Your include path contains your project?

|-Include Path
    |
    - My Test Project
        |
         - MyClass.php

This is your dir structure? It's really strange and not sure if it's supported...
Comment 2 DanForys 2012-10-09 09:00:10 UTC
Yes. That's right.

Perhaps if I explain the background, the layout might seem a little more sane :)

At work, we have a very large number of libraries, including Zend Framework and our own extensions. Specifically in my team we provide libraries used by the entire organisation. These libraries could be installed as RPMs in our (virtualised) development environments, or checked out onto host machines.

In order to have code-completion (and xdebug) working across all of these libraries, I periodically copy the dev environment libraries into a single folder on my machine. This is the folder in my NetBeans include path. Unfortunately, this also means that there could be duplicated files between the library folder and my working copy.

If I edit any of these files in the include path, or have a duplicate in my working copy then the code completion of the edits is totally non-functional.

It seems to me that workaround would be manually adding each library as an include path, checking for duplicates and taking care to omit the current project. Whilst this is possible, it is rather time consuming. Especially to do this for every project.

Happy to concede that this is unusual perhaps for most NetBeans users, but fairly likely in our organisation.
Comment 3 Ondrej Brejla 2012-10-09 09:22:35 UTC
Ok, I understand you, but as you wrote, it's quite unusual use case for most of users so for me, it's rather an enhancement to improve the functionallity than a defect :)
Comment 4 DanForys 2012-10-09 09:26:50 UTC
Fair enough. Thank you!