On 11 June 2010 01:36, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 10 Jun 2010 22:59:11 +1000 Lex Trotman elextr@gmail.com wrote:
What I would suggest is that upon project creation you make a complete copy
Thats just what I didn't want to do, remember there are filetype commands and execute commands too makes each project copy big.
Then I would suggest that there are no per-project filetype commands and you just copy the global ones. In project you care about a set of files so global/general/non-filetype options are the ones you want to change. This seems to be the most reasonable solution now.
I have argued that project filetype commands are useful, but you have a good argument here. Perhaps the complexity is not worth it when project non-filetype commands could suffice.
You could probably make an argument that non-filetype commands are sufficient for C/C++ and other "building a big thing" type languages, but other filetypes supported by Geany are more centred around the individual file.
And don't think just in terms of compile/link type operations.
I don't think that the potential uses of filetype commands have been explored much, even for C/C++ there is code analysis tools, prettyfiers, hey I'm giving myself ideas here..
And then it becomes important to be able to configure them per project. Also don't think of it as one project file per source tree,
The point was that if you want to override the non-project filetype commands you could do that with project non-filetype commands.
It might be less nice to use though, so I'm not suggesting implementing it, just thinking out loud a bit.
Thinking is good, but how would you specify which non-project filetype command would be overridden by which project non-filetype command and not confuse things further?
We have to get that terminology sorted out don't we :-)
I'm using multiple project files to save the differing configurations when using differing tool sets for the same source tree.
We also have the filetype dependent execute commands to consider, pointing to the executables in the build directory rather than in the source directory is likely to be common.
I think of those grouped in with filetype commands, they just do different things :-p
True, I just wanted to make sure that they weren't forgotten.
I also like the copying non-project commands into the project idea.
Makes the whole thing easier to implement of course, but then for the common things, the user has to change it in all project files.
I don't think its a good idea for filetype commands though, and even for the executes it is a bit of a load copying all languages just to edit one.
I wasn't suggesting copying those into the project file, but only if we didn't have project filetype commands (and project filetype execute commands - phew).
Ok.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel