On 2015-12-29 3:24 AM, Lex Trotman wrote:
My only comment is to add to the point that the build commands are different. For example C that uses "template" as a variable won't compile with C++, a trap for beginners or existing code (just like Geany used to have).
It's probably best that beginners learn early why using "template" or other C++ keywords is a rather bad idea, even in plain C. But yeah, there's otherwise a pretty big difference between languages/compilers.
But I would like to also propose (again) an orthogonal split, C/C++ headers from C/C++ bodies. The headers need different compile commands from the bodies. Using the same command as happens now generates a pre-compiled header file, and then any changes to the header source are not seen when the body is compiled.
As mentioned below, individual file-specific compile-commands is not very useful, at least with C or C++.
This can waste significant time, just because the user hit compile after fixing a header issue, but before switching back to the body file. Its a really nasty trap waiting for the unaware or beginner, and one which we shouldn't be creating.
This is more of a bug that (some) build-commands are bound to individual files, which is generally never useful. In most IDEs (including Geany), when you trigger a rebuild/re-run, it saves all the files and runs the project's build system. Geany supports this fine, and I've never personally found any of the file-specific build commands useful. IMO, if you trigger a filetype-specific build command on a header, building a pre-compiled header file is a perfectly reasonable thing to do (why would you individually compile a header otherwise, anyway? Only reason I can see is "on accident").
As an alternative to separate filetypes, both of these problems could be avoided if build commands could be different for different extensions. then one C/C++ filetype is definitely more viable.
Sounds like it would be useful.
Cheers, Matthew Brush