Re: [cdt-patch] Outline Open Include patch

["Thomas Fletcher" <thomasf@xxxxxxx>]

Alain Magloire <alain@xxxxxxx> said:
> > 
> > Folks,
> >   
> >   Here another CDT 1.2.x and CDT 2.0 patch corresponding to PR 51355.
> > This patch extends the search for an included file from the defined
> > include paths to the local project.  This is only done in the case
> > where searching the defined include paths provided no results.  This
> > allows a user to have both a properly configured environment (which
> > will return only the "valid" header files) and a mis-configured 
> > environment, favouring the properly configured environment.
> > 
> >   Additionally the local project search is improved to use a proxy
> > and then to match project entries only where they make sense.  For
> > example if you were looking for #include "a/b.h" and you had a 
> > path c/b.h then it would _not_ be reported since you explicitly
> > indicated the path.
> > 
> > For the ChangeLog:
> > 
> > - Extend the scope of the search for an include entry to the local
> >   project if no results are found in the defined paths.  
> >   Improve the performance by using an IResourceProxyVisitor
> 
> It is something in the future that we do not want to have.
> This behaviour is inconsistent and confusing for the user.
> It gives the impression that things work ok, but other modules fail...
> For example, the indexer still can not find the files, the builder is
> always failing .....
> content assist can not complete etc ...
> but the users cry, the outliner find the includes ... what is wrong !!!

I agree that the inconsistancy is a terrible thing to have.  On the other
hand, when people try and accomplish what they do with a tool like 
UltraEdit, SlickEdit (which provide C/C++ context type navigation) then
things don't work they will still cry out.  
  
The fact that they haven't properly configured the "environment" may 
very well be true, but what do we do to help with this situation?
- Importing a standard make project you have to add include paths one
  at a time (not very handy if you have N hundred paths to add)
- The imported paths/configurations have no "variable" knowledge and 
  can't be shared between users with different roots.
 
> To ease things for the user, currently, the branch and the head do
> fallback to scan the project.
> At least until the ICPathEntry and ScannerInfo stuff gets cleared away.

Except that you only fall back in the case where there are no defined
headers.  In the case I'm indicating, there are defined includes, but
perhaps the user has missed one, or perhaps the include was actually 
a local include:
#include "thomas.cpp"
which doesn't need to be in the include paths to be picked up.
 
> You are probably have an outdated repository.  Try to update.
> If it does not do what you want, let me know.

Nope, my 1.2.x branch is synchronized.  If you look at the patch, 
it only falls back in the case where there are no entries _found_
in the defined include locations.  Perhaps an additional enhancement
would be to prompt the user to indicate that the header was not
found in the include locations, do you want to search the project
and then when it is found then prompt them to add it to the include
paths.

I realize that 1.2 is not fully configured yet and that perhaps with
2.0 this won't occur ... but I think that if we are going to hold the
line on "A project must be properly configured to work in high runner
cases" then we need to be more pro-active about helping the user fix
those cases.  I know that John and Bogdan are working hard on this 
from the parser indexer side, and I'm happy to work on improving things
on the "small bits of editing", but as was pointed out to me ... "reading
and developing code you need to have a more flexible context than a
compiler".

In any case let me know how to "improve" this patch (ie where it is
better to address the shortcomings) and I'll go and do that instead.

Thanks,
 Thomas  ... full of opinions these days =;-)