Project Organizer: Set header filetype to match source filetype
Resolves #1121. Resolves geany/geany#2946.
If file is a header and a corresponding source file is found in the same directory, set the header filetype to match the source filetype. Otherwise, search the project for the corresponding source file. This is useful for .h files, which are ambiguous for C/C++. Does not address the filetypes of isolated header files.
@techee
I just don't like that there are now 2 more or less identical implementations... I think the implementations could be unified as follows:
I will update the PR after making the changes you've suggested.
IMO ProjectOrganizer should work on the files in the project only.
For the most part that is still the case. But Geany can still open files that are outside of the current project. For those files in particular, it would make sense to be able to switch source/header files and set header file types when the files are in the same folder.
For the most part that is still the case. But Geany can still open files that are outside of the current project. For those files in particular, it would make sense to be able to switch source/header files and set header file types when the files are in the same folder.
OK, makes sense.
Thanks. Could you squash the first commit "Project Organizer: Set header filetype to match source filetype" with the third commit "Combine common code between swap header/source..." so this change is easier to review?
I must say I'm not a big fan of the last commit "Set header filetype to match source filetype". Project organizer, as the name suggests, serves for working with projects and isn't meant to do anything when projects aren't open. There's the "Code navigation plugin" for non-project header/source swapping. So I'd prefer this commit to be removed from this pull request.
@techee I'll combine commits when I get a chance.
The reasons to make the function work when a project isn't loaded:
- swapping headers isn't inherently project specific.
- If two plugins provide basically the same functionality, one for projects, the other not, they would need multiple keybindings and users would have to keep track of which plugin/keybinding to use when a project is or isn't loaded.
Hmm, well, yeah, I can probably survive if this patch stays even though I don't like much when a plugin does something that's not obvious that it does...
If a general config is added for the open folder and terminal commands, it would be less not obvious that the plugin can do some things that are not strictly project oriented. I'd expect it would remain limited to features that benefit from project integration.
I combined the commits. The change that lets it work when a project isn't loaded is:
if (prj_org)
{
header_patterns = get_precompiled_patterns(prj_org->header_patterns);
source_patterns = get_precompiled_patterns(prj_org->source_patterns);
}
else
{
// use default header/source patterns if project isn't open
gchar **headers, **source;
headers = g_strsplit(PRJORG_PATTERNS_HEADER, " ", -1);
source = g_strsplit(PRJORG_PATTERNS_SOURCE, " ", -1);
header_patterns = get_precompiled_patterns(headers);
source_patterns = get_precompiled_patterns(source);
g_strfreev(headers);
g_strfreev(source);
}
If a general config is added to set commands for open folder/terminal, an option to set preferred header/source file extensions could be added as well. Rather than mess with it in this or the open folder/terminal PRs, I'd prefer to open (yet another) PR specifically to add general preferences.
@techee I made the change you requested. Let me know if you want the commits squashed again.
@techee I made the change you requested. Let me know if you want the commits squashed again.
Yes, please. Apart from this change there's no more work to do I think and this PR will be ready for merging.
@techee I assume squashed commits if your preference, so I will also squash the commit I made to another PR.
@techee I assume squashed commits if your preference, so I will also squash the commit I made to another PR.
Well, when it's a feature commit, I prefer them separately, but when it's just a fix based on review, it's better not to clutter the geany-plugins git history with these.
Anyway, the pull request looks good and can be merged I think (can take some time based on Frank's availability),
@techee Thank you.