On Mon, 12 Jul 2010 13:21:03 +0200 Jiří Techet <tec...@gmail.com> wrote:
> On Sun, Jul 11, 2010 at 15:19, Dimitar Zhekov <dimitar.zhe...@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. -- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel