Community
Participate
Working Groups
org.eclipse.cdt.internal.ui.util.EditorUtility:388 picks random project when opening non-workspace source file that is not on include path of any workspace project. This has several consequences: 1. Editor behavior on the same file differs depending on whether or not there are any projects in the workspace. Editor tab will show different icon, semantic highlight will be disabled, markers will not be supported (https://bugs.eclipse.org/371144) 2. Editor behavior would differ depending on the project selected - i.e. different regions of the code will be marked inactive depending on the project macro values. 3. Markers may be deleted unexpectedly when user deletes entirely unrelated project. I would like to prepare a patch that will see if the workspace has special hidden project (i.e. named ".cdtexternalfiles") and will create one. Than that project will be used as a basis for viewing/editing non-workspace files that are not on the include path of any project. I tried this in our product and so far I am satisfied with editor behavior: 1. File editors behave the same regardless of the workspace projects. 2. Most advanced features work as expected. So far the only issue I have found is that inactive areas highlight is completely bogus. I don't think this may be considered a regression as it is pretty irrelevant even in the current implementation (when settings are read from a random workspace project). We could update inactive code highlight so it would test project preference scope and disable it for this special project.
(In reply to comment #0) > I would like to prepare a patch that will see if the workspace has special > hidden project (i.e. named ".cdtexternalfiles") and will create one. Than that > project will be used as a basis for viewing/editing non-workspace files that > are not on the include path of any project. This behavior is definitely not suitable to be used by default. In cases when the workspace contains a single C/C++ project, I definitely want this project to govern operations on non-workspace files.
(In reply to comment #1) > This behavior is definitely not suitable to be used by default. In cases when > the workspace contains a single C/C++ project, I definitely want this project > to govern operations on non-workspace files. Maybe it should be made a special case? I.e. use workspace project when there's only one project in the workspace but create a special project otherwise. My concern is that project selection is fairly arbitrary when there's more then one project in the workspace.
Created attachment 211069 [details] Patch with the suggested fix This is first iteration of the fix, tested locally (I've seen both semantic highlight and markers working on non-workbench files in "empty" project). It will use user workbench projects in following cases: 1. There is only one workbench project and it is a user project. 2. There are two workspace projects and one of them is this new "synthetic" project. 3. Non-workbench file is on the include path of the user project. In all other cases it will attempt to create a synthetic project or use existing one. I added 3 hidden preferences for product developers that allow disabling this project creation, changing project name or making it non-hidden. Please note that this patch requires fix for https://bugs.eclipse.org/371561 applied as otherwise CDT Model will ignore hidden project.
What if I create a new workspace intended to include only a single project? What do you do during the time there's zero projects? And how do you react when that single project is created? What if I navigate from a file in one project to an external file. I would likely want to use the settings in that project for that external file? I don't want to mess things up too badly to support this behaviour. When I open an external file that isn't related to any of my projects, I use Emacs.
The goal is not to harm - so the behavior will be the same in most scenarios. (In reply to comment #4) > What if I create a new workspace intended to include only a single project? User project will be used as a context for non-workspace files if there is only one user project in the workspace. > What do you do during the time there's zero projects? Special project will be created for opening non-workspace files. > And how do you react when that single project is created? The code will use user project if the workspace contains only one user project and one "synthetic" project. > What if I navigate from a file in one project to an external file. I would > likely want to use the settings in that project for that external file? Original implementation would check if non-workspace file is on the include path of any workspace project and use that project. If the external file is not on the include path of any workspace project then "random" (the first one) will be used. Proposed patch will change this behavior in that the CDT will use a special project if the non-workspace file is not on the include path of any workspace projects. > I don't want to mess things up too badly to support this behaviour. When I open > an external file that isn't related to any of my projects, I use Emacs. We see definite value in using CDT as a source viewer in our RCP tool (this tool does not expose notion of the workspace and projects to the users). We provide some advanced semantic highlight (it will be a basis for our proposal - https://bugs.eclipse.org/363406) that are not available in emacs or other editors - but to enable them in RCP scenario currently we need a project in the workspace. Also we are considering creating RCP-based debugger - as the CDT already allows starting the debug session on the executable without any workspace project. I believe that RCP scenarios may be interesting to other adopters as well. Smaller RCP-based tools (debugger frontends, profilers, code analysers) that do not require setting up projects and such may become a "gateway drug" for the non-IDE users to the CDT.
CQ:WIND00376876 We have an open request to fix this issue in our product. Doug, do you feel that Eugene's proposed solution would cause more harm than good?
Doug, I can update both this patch and patch for #371561 for master/8.1.x and submit them to the Gerrit if needed.
In the Oct 2. call (http://wiki.eclipse.org/CDT/calls/Oct2012) we discussed the hidden project solution and concluded that the parser should be running even without a project.
*** Bug 404792 has been marked as a duplicate of this bug. ***
CQ:WIND00-WB4-740
