Bug 160143

I'm not sure of the usefulness of this feature as it highly depends on the buildsystem. As soon as the buildsystem doesn't provide the needed include directories this will not work and that might confuse users a lot: "Why doesn't it search in the included files in project foo when it does in project bar, where do I activate that?"

BTW: What do you mean with "Emergency"?

Andreas,

> I'm not sure of the usefulness of this feature as it highly depends on the
> buildsystem.

In a way it is a user problem, user could also make a few typos in includes as well.

> that might confuse users a lot:

Also true, but on the other hand it is better to constantly improve specific tool, then not introducing it because of that reason.

> BTW: What do you mean with "Emergency"? 

It was rather humorous use ;-) I work at rather complex projects at the same time and it is useful for me to just open a file, look at it, find function/method I needed and then search for something this method refers to. 
But the opened file is not from current project and it is not from current directory. 

Currently I can only mimic it by searching the main directory of all my programs, but it is way more lengthy process.

With kdevelop-4 this will be easy to implement at least in C++, because it keeps all the necessary information anyway. However ot probably still won't be necessary, because you can also easily search all visibly declarations(also those from included files) using the quickopen list.

#2: I wasn't saying this shouldn't be introduced :) I was just raising a concern.

As far as finding references of a method or similar things, thats not a use-case for find-in-files actually. Thats something the language support needs to provide and in KDevelop4 it does.

#3: David: IIRC that only works for non-project files that sit inside a directory with some kind of Makefile, so you can run make to find used includes, right? So my concern still stands, that it only works in some cases.

David,

  Find in files is much more powerful, you can see not only declarations, you can search for variations of the text.

Andreas,

  Yes, it is more language specific than other find modes. And about makefiles -- it would _not_ work if you define your own include path and then just type
#include "foo.h"
instead
#include "mypath/foo.h"

but then again -- it is better to have something and improve, than nothing at all :-)

  And I don't know how about you, but I just "see" it that it fits the find in files dialogs quite perfectly: (find)
a) directory based
b) project based
c) file content based
  All you can ask for :-)

#6: Find-In-Files won't be language specific, it cannot depend on C++ support, it won't ever know that these are #include directives. However luckily our language support already has ways of expression that at this point there are symbols imported into the current context that come from different files. Also IIRC we have support to get at the actual filename for such imported context. So this will actually work for all languages that support import/include directives, when it is implemented. So all that can fail is the language support finding the actual file that is imported/included and thus it can't parse it.

Thats KDevelop4 material - of course.

And btw: Thinking about this a bit more, I actually like the idea of utilizing our language-infrastructure to support this.

Actually, despite my last comment, I think this would be very useful.

@Andreas:
It would work with all files where the C++ support in general works. The C++ support shows errors in the problem-reporter like "included file was not found", so the user would have a chance to see whether the search is complete.

The include-paths can come from the build-manager or through the Makefile include-path resolver. Additionally for non-project files, kdevelop first tries to see whether the file was once included into an already parsed file, and re-use that include-path if available.

So it should mostly work.

Hi,

I have been trying to sketch a specification for this feature request. I’ve got the following points:

- Add the “Included Files” option to the “Location(s)” drop-down list in the Find In Files dialog.
- At the right side of the “Recursive” checkbox, there should be a “Depth” SpinEdit control to indicate a inclusion depth level, with the following possible values: Infinite (as recursively currently behaves), 1 (only included from the current file), 2 (included from this file and from files included from this file), etc.
  - The control would be disabled (grayed out) if the “Recursive” field is unmarked.
  - For coherency, the Depth field should also be implemented for the rest of the existing “Location” values, based on directory levels (instead of inclusion levels).
- The rest of the fields in the Find In Files dialog should work fine with the new Location option.
  - To be noted that the “Limit to Project Files” checkbox applies to this new option as well.
- The new Location option should only be available (listed in the drop-down menu) when the current file supports inclusion.
  - It should be available, for example, for C++ (#include), PHP (include, require, etc.) and Python (import).
  - It should not be available, for example, for .txt files.

Am I missing something?

Also, writting them a couple of questions araised:
- If the current file supports inclusion but there is no actual inclusion statement in it, should the drop-down list for the search location provide this new option?
- If the current file supports inclusion and has inclusion statements but they are all unresolved, should the drop-down list for the search location provide this new option?

What do you think?

Git commit c0d4221d344b47f29a7862c4bc086e0a7a8bae7c by Kevin Funk.
Committed on 21/02/2013 at 11:12.
Pushed by kfunk into branch 'master'.

Find in Files: Allow depth definition

Initial patch by Adrián Chaves Fernández.
Thanks for the patch!

More changes:
* Factor out "bool isInDirectory(...)"
* Remove the anonymous enum polluting the root namespace
REVIEW: 105856

M  +5    -5    plugins/grepview/grepdialog.cpp
M  +2    -1    plugins/grepview/grepdialog.h
M  +55   -12   plugins/grepview/grepfindthread.cpp
M  +4    -3    plugins/grepview/grepfindthread.h
M  +3    -3    plugins/grepview/grepjob.cpp
M  +3    -3    plugins/grepview/grepjob.h
M  +14   -8    plugins/grepview/grepwidget.ui
M  +1    -1    plugins/grepview/tests/findreplacetest.cpp

http://commits.kde.org/kdevplatform/c0d4221d344b47f29a7862c4bc086e0a7a8bae7c