Bug 160143 - find in files: search in included files
Summary: find in files: search in included files
Status: CONFIRMED
Alias: None
Product: kdevplatform
Classification: Developer tools
Component: grepview (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-31 08:02 UTC by Maciej Pilichowski
Modified: 2014-01-25 01:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2008-03-31 08:02:02 UTC
Version:            (using KDE 3.5.8)
Installed from:    SuSE RPMs

In case of "emergency" it would be useful to search in included files, in case of C++

#include "something.h"

if additionally user selected "recursive search", included files in included files (and so on) should be then search.
Comment 1 Andreas Pakulat 2008-03-31 10:13:55 UTC
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"?
Comment 2 Maciej Pilichowski 2008-03-31 10:32:51 UTC
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.
Comment 3 David Nolden 2008-03-31 10:59:48 UTC
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.
Comment 4 Andreas Pakulat 2008-03-31 12:08:07 UTC
#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.
Comment 5 Andreas Pakulat 2008-03-31 12:10:52 UTC
#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.
Comment 6 Maciej Pilichowski 2008-03-31 12:16:39 UTC
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 :-)
Comment 7 Andreas Pakulat 2008-03-31 12:26:02 UTC
#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.
Comment 8 David Nolden 2008-03-31 13:24:58 UTC
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.
Comment 9 Adrián Chaves (Gallaecio) 2012-08-04 08:29:20 UTC
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?
Comment 10 Kevin Funk 2013-02-21 10:17:49 UTC
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