On Mon, 12 Jul 2010 13:21:03 +0200 Jiří Techet techet@gmail.com wrote:
On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 9 Jul 2010 23:36:06 +0200
Why have per-project source / header list, instead of global? No matter the project, it's quite unlikely that a .c file will ever become a header, or .h will be source. You can move Source and Header files at plugin level, put there long lists of well-known source and header files, and let the user edit them.
This won't work. The main reason why the patterns are present is not to include as many files to the project as possible (one could use * then), but to get rid of as many uninteresting files as possible. In what you suggest all the source files would be visible in the project
- but I don't want that. [...]
Ah, my explanation wasn't clear enough. The global gproject pattern settings should _only_ be used to classify what files are source and what are header, since gproject needs this data. These settings are _not_ the project patterns. I'll refer to them as "extensions" (they should be probably implemented as patterns for flexibility).
The project patterns, OHOH, are entered as a single list in the Geany project patterns field (currently not displayed). gproject reads them, searches the project directory, and for each file found looks in the gproject h/s settings to classify it as "source", "header" or "other".
For example:
gproject sources - "*.c *.cpp *.s *.idl...", whatever list of well-known source extensions you come with.
gproject headers - "*.h *.hpp ...", personally I'll add "*.def *.dgl".
Geany patterns for a particular project: "*.c *.h Makefile.*".
Techically, in a such scheme Geany will fully support/control the project patterns which can be also be used by Geany FIF and and other plugins; while gproject will contain the file type classification, which is only used by gproject.
From users POV, I won't need to create 3 patterns for each project,
always specifying that "*.h" is header, "*.c" is source, and "Makefile.*" is other. The last pattern does not match any gproject directly; when using a separate build directory, I can even specify a single "*", and gproject will still classify the files properly. :)
The limitation of the global classification is, of course, that it's global. So you won't be able to specify "*.h" as header files for the normal projects, and as "source" for a specific project, like your first example (.idl -> .h). But in the example, you don't want to see them, and they are not real "source" files anywas. In fact, I know not of any "questionable" extensions, and my guess (which can of course be wrong) is that they are uncommon enough not to pose a problem for a single user.
I think someone already suggested it, but how about a single push button, with the Copy icon for example, that'll copy the project patterns in the edit field? Even make it "autoclick" when a project is loaded. Switching forth to Project and back to Custom seems a bit clumsy.
The reason why I would prefer it the way I suggested is that if you select project, the patterns will be updated automatically whenever you load a project. I'm afraid that the "autoclick" feature would be more confusing/annoying if you specify your custom patterns and they get overwritten every time you load a project.
The custom patterns will be saved in the history; when switching to another project, chances are that I'll want it's patterns, at least as a starting point for customization.
On the other hand, when you select "project" in the combo box, you explicitly say that you want it this way.
Yes. But to remove a single pattern, you need to select "Project" to fill the text entry, then "Custom", and only then edit the list.
Well, the 3-state combo is a bit clumsy and unusual, but I can live with that.