On Fri, 9 Jul 2010 22:53:17 +0200 Jiří Techet techet@gmail.com wrote:
Can you send the patches by email please - my git-fu is not yet good enough (slowly improving though).
OK, will do (maybe I'll wait for a while to collect everyone else's comments and possibly modify the patches).
Suits me :)
Use project patterns in the FIF dialog
When "use project patterns" is selected, the project patterns are copied to the "files" edit box and it becomes not editable. It should be considered whether the "files" checkbox should exist - it may not be clear if the edit box is greyed out because "use project patterns" is selected or because "files" is unselected. The "use project patterns" checkbox is inactive when no project is loaded.
Maybe
Hmm, I still need to check the code properly, but I'm having second thoughts about this. Simpler alternatives would be:
- Always append project patterns to the Files drop-down list on
showing the dialog (if it's not already there), it's up to the user to choose it.
But this also means that every time a project is opened, the patterns have to be selected manually from the list (easy to forget to do so and it also won't be clear to the user which patterns in the list belong to the project).
- An API function to show the dialog with an argument for file
patterns.
I think it wouldn't be a good idea to force the patterns every time the dialog is opened (neither by default nor by any plugin). The user may have customized the patterns and this would just reset them.
The advantage would be that the dialog is simpler - less controls & complexity.
OK, I have one more idea how the dialog might look like, see the mockups below:
http://dl.dropbox.com/u/2554438/fif1.png http://dl.dropbox.com/u/2554438/fif2.png
For "all" and "project" the patterns entry would be disabled (for project it would display the project's patterns). I think this solution doesn't add much complexity - the two-state check button just changes to three-state combo box.
This looks good to me.
(The "generate tags" entry is related to my other plugin, which is currently a work in progress. With this plugin you can generate the ctags file using this entry (all files under the base path satisfying the patterns are included) and then, use the editor's context menu to find the given tag. You can find the result of such a search in the message window in the screenshot. The tag manager that geany uses is too slow for big projects so I can't use it for this purpose.)
I'm not sure that could integrate with Geany's tag functionality, but it's up to you.
The reason is simplicity. This plugin was one afternoon work for me. I
OK, just wanted to mention it. E.g. Go to Tag commands, etc.
I spent very limited time looking at the tag manager so the following can be quite wrong. From what I have seen it creates some object hierarchy by going through the objects and for every object finding the related object (quadratic complexity at least). Probably this could be improved by using hash tables instead of lists but I would really have to dig into the code deeply to understand it and find where the bottlenecks are. In contrast, ctags tag generation is mostly (apart from sorting the tag file) linear. Just for illustration, for linux kernel the generation of the 140MB tag file containing about 1.6 million entries from all *.c and *.h files takes less than 20s.
In fact I think the best way to develop the tag manager would be _outside_ of geany so all other editors could benefit from it. Unfortunately from what I can see both tag manager and slightly less ctags are rather dead.
Anjuta used to use tagmanager but IIUC they now use a GtkTreeModel to store CTags-parsed info, I haven't looked at it.
Prevent -Wmissing-prototypes report warning when compiling a plugin
We discussed this before. A plugin would also need prototypes for the other functions like plugin_init. So I said we could change the doc/pluginsymbols.c file into a header to do this.
I know, this is a complete set of patches I use against geany.
But I don't understand why the plugins would need doc/pluginsymbols.c to be changed to doc/pluginsymbols.h - I thought this was needed if geany itself was compiled with the flag (I haven't tried it myself so I don't know what's needed for that).
It's currently just for generating documentation.
plugin_init() has to be implemented by the plugin so all the plugin has to do is to declare the function as well before it implements it. At least for gproject this patch is all I need to compile it without warnings.
I thought it would be easier to avoid having to declare e.g. plugin_init and other function symbols.
I'll leave it up to you - if you decide for changing the source file into a header, it's better when it's done by you as I might break some things I'm not aware of.
OK.
Regards, Nick