Project -> Properties -> Project Organizer dialog has number of project properties: Source patterns, Header patterns, Ignored file patterns, Ignored directory patterns.
Menu -> Project -> Find in Project Files (it is a tool provided by Project Organizer) does not respect project settings mentioned above and searches all files in project directory, including ignored files and files in ignored directories.
That is the intended/implemented behaviour, see the remark from the Project Organizer tab in the Project Properties dialog:
Note: the patterns above affect only the sidebar and are not used in the Find in Files dialog. You can further restrict the files belonging to the project by setting the File Patterns under the Project tab (these are also used for the Find in Files dialog).
So this is not a bug. It would be an enhancement.
@LarsGit223 Probably project organiser should be using the patterns in the Geany project settings unless there is some good use-case for a different set. In which case they would want to be separate from the FIF ones anyway.
The Geany project patterns list is in the plugins API so PO should be able to get them to use.
Having only one set of patterns is likely to be less confusing to the users.
@elextr: I agree that it would be nicer for the user if all patterns where the same in all plugins and in geany itself.
But I disagree in the point that Project Organizer should use geany's patterns. By the way the workbench plugin is also not using geany's patterns. If I write a plugin I do it for the reason that I want to implement something which is different or missing in geany itself. So it does not make sense IMHO to limit the patterns to the one's of geany.
...unless there is some good use-case for a different set
Well, I guess the author has seen some use cases otherwise he probably would not have spent the time in writing the code for it.
It's right it would be nicer. But it is a project plugin so it is not surprising that it does not re-use all settings of the standard geany project management. I think unless the author does see a reason to change the Project Organizer patterns I would simply rate this as an enhancement/feature request and keep the patterns in Project Organizer unchanged.
@LarsGit223 oops I thought you had taken over this one, sorry and apologies to @techee :-D
My reasoning for why plugins should use the settings from Geany (assuming they have the same basic form) is that the Geany settings exist even if the plugin is not loaded, and they don't go away if a plugin adds another version of the same setting. So now there are two places for the same setting. And one is used in some places and the other setting is used in other places. That leads to the sort of confusion the OP reported.
Obviously if the settings do something different and there is a good reason to have both then fine, just clearly document which functions use which setting, and possibly why, so users understand the thinking behind the decision.
So this is not a bug. It would be an enhancement.
To me this declared but not implemented feature. What the point in "Find in Project Files" if it is just an another (and misleading!) name for "Find in Files"?
"Find in Project Files" can be easily implemented by passing few more options to `grep`: `--exclude` (once for every ignored file pattern) and `--exclude-dir` (once for every ignored dir pattern).
For searching in files, ProjectOrganizer just uses Geany's standard search using grep and there's no API in Geany that would allow ProjectOrganizer pass the ignored files/directories to Geany. In fact, Geany itself doesn't support patterns for excluded files/directories - the reason is that `--exclude` and `--exclude-dir` parameters of grep aren't present in older versions of grep and it's not guaranteed they would work.
There's nothing that could be done in the plugin to address this issue. Plugins cannot add extra parameters to grep - it's done by Geany when using the "Project" settings in the "Find in Files" dialog and when patterns are entered in the Geany's part of the Project settings.
As a workaround I'd suggest selecting "Extra Options" in the Find in Files dialog and entering `--exclude-dir=pattern` where `pattern` corresponds to the directories you want to ignore.
@techee
I do understand that there are (or could be) some problems to implement "Find in Project Files" which will search in project files, as they defined by Project Organizer.
But I do *not* understand what the point in "Find In Project Files" (a menu item added by Project Organizer!) which simply can't search in *project files*, as they defined by Project Organizer. "Find In Project Files" is useless and misleading. It has no value.
@techee thanks for the explanation, the plugins "project file patterns" are there to define where you tag parse for symbols I presume, not really anything to do with searching. So a separate setting is perfectly fine.
So yeah it would be an enhancement for PO to add its own search mechanism using its own settings to avoid Geanys search, which tries to be helpful to beginners with a partly GUI driven search, but that makes it unsuitable for your purposes.
Lemme say on your behalf "pull requests are welcome" :)
But I do not understand what the point in "Find In Project Files" (a menu item added by Project Organizer!) which simply can't search in project files, as they defined by Project Organizer.
Well, it searches in the project directory where, you know, the project files are...
It has no value since it is just an alias for "Find in Files".
Except that it searches in the project directory instead of the directory of the current file.
the plugins "project file patterns" are there to define where you tag parse for symbols I presume, not really anything to do with searching.
Nope, they are used for searching alright when you select "Project" in the "Find in Files" dialog. But these patterns are used to define which files/directories to search in (such as *.c) and not which files/directories NOT to search in (such as .git) which is what @van-de-bugger suggests.
@techee what about a checkbox near the ignored file patterns textboxes like "exclude these patterns from searches (requires compatible grep command)" which would put `--exclude` options in the "Extra options" box? It would require adding a new function or two to the plugin API or registering the associated FiF widgets using `ui_hookup_widget`, but that shouldn't be a problem to add. Of course someone interested enough would have to actually do it :)
@techee Ahh, your explanation above says no way of passing __ignored__ file patterns, I misread that as no way of passing any file patterns. So how do you pass them? By modifying the GStrv in the projects structure? If so I do hope thats intended to work, its not documented to work (or not) :)
So yeah, ok, the options are either upgrade Geany to support excluded patterns (would be nice) or as @codebrainz notes to allow setting the extra options or implement your own complete search capability.
So how do you pass them? By modifying the GStrv in the projects structure?
@elextr The plugin doesn't pass them at all - it's all done by Geany. Users enter the patterns into Project->File Patterns and if Project is selected in the FIF dialog, Geany uses them. It happens the same way even if the ProjectOrganizer plugin isn't installed, nothing done on the plugin side related to this.
@codebrainz Adding stuff directly to the dialog isn't a good idea - it would stay there because Geany remembers what you enter there and on every project open you'd add more and more stuff (yes, you could parse the contents of "Extra options" and remove what you added but there's a danger you'd remove something what the user entered manually).
So yes, one option is to add some API to Geany to support this but maybe even better is to add an entry with excluded patterns directly to Geany's Project dialog plus the "enable" checkbox as you suggest. And I guess many people would like to see it in the FIF dialog too.
@techee uh isn't that what I said? "the __plugins__ "project file patterns" are there to define where you tag parse for symbols I presume, __not__ really anything to do with searching" (emphasis added)
Good point about the removal of stuff added to the Geany dialogs from outside, plus they would be saved if the project properties are saved at any time, lets not go there.
but maybe even better is to add an entry with excluded patterns directly to Geany's Project dialog plus the "enable" checkbox as you suggest.
Presumably you actually mean "extra options" since Geany FIF does not know about excludes. If its taught how to handle excludes then adding them to FIF dialog is a no brainer.
I think @codebrainz was suggesting the checkbox next to the __plugin__ textboxes to tell the plugin not to add stuff to the Geany dialog.
If its in Geany I don't see the need for a checkbox, if you don't want it used, don't enter it or don't select project on the FIF dialog?
But now having that selection next to just the includes may be confusing if it selects something else as well.
@elextr No, it isn't correct. The first part of the sentence isn't correct:
"the plugins "project file patterns" are there to define where you tag parse for symbols I presume
because this is controlled by the plugin. More importantly for this case, the se second part of the sentence isn't correct:
not really anything to do with searching
because this is exactly what the pattern list is for (please check the tooltip Geany gives you when you hover over the edit box and re-read what I have written in the posts above and try it in Geany).
Presumably you actually mean "extra options" since Geany FIF does not know about excludes. If its taught how to handle excludes then adding them to FIF dialog is a no brainer.
I meant the second option - "teaching" Geany about excludes by adding them both to the Project dialog and FIF dialog.
If its in Geany I don't see the need for a checkbox, if you don't want it used, don't enter it or don't select project on the FIF dialog?
I was mentioning it because of possibly incompatible grep where it might not work - but yeah, the checkbox can be omitted.
@techee since the only time I have run PO was to look at this I am probably causing the confusion by using totally incorrect terminology. By "plugin project file patterns" I mean the header/source/ignored/ignored dir entries in the "project organiser" tab of the project properties dialog. IIUC these are plugin settings.
IIUC these are used by the plugin for gathering tags/symbols for the whole project.
They have no effect on FIF as far as I can see, as I understand it, and as I understand you to be saying, FIF is totally a Geany function using the include patterns in the standard project settings.
So what does the plugins `Project->Find in project files` menu item add? It seems to just open the standard FIF dialog, and so I am saying I can see why its confusing to users if its part of the plugin menu items but does the same as the standard `Search->Find in Files` menu item.
So what does the plugins Project->Find in project files menu item add? It seems to just open the standard FIF dialog, and so I am saying I can see why its confusing to users if its part of the plugin menu items but does the same as the standard Search->Find in Files menu item.
As I said above, it does exactly what it says on the tin...it searches in the project directory, where the project files are. It's a bit hard to fit "Open the Find in Files dialog with the project directory pre-filled in the Directory textbox for you" in the main menu :)
@codebrainz ahh, I didn't notice the pre-filled directory, ok, so its actually "Find in Project Dir..." not "Find in Project Files..." and its even two chars shorter :)
Presumably it was named to keep some relation to the feature it invokes ("Find in Files") but add some specificity. More accurately it could be called "Find in Files in Project Directory", to not make it sound like it's looking _for_ files in the project directory but rather looking _in_ files in the project directory. On the other hand, the [documentation](https://plugins.geany.org/projectorganizer.html#project-menu-entries) tells what it does, and we all know everybody reads the documentation :)
github-comments@lists.geany.org