On Mon, 10 Nov 2008 13:07:14 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Mon, 10 Nov 2008 14:10:04 +1100 "Lex Trotman" elextr@gmail.com wrote:
Currently using C or C++ as the filetype for headers works for highlighting (except for C++ .h files which are taken to be C, so things such as template or namespace are not highlighted).
Maybe they could just be detected as C++.
This would only solve the problem of highlighting, but we still can't auto detect if the opened .h file is C or C++. Opening a C header file as C++ should highlight it fine but all symbols in this file are missing in other C files for auto completion, same when opening a C++ header file as C. We could simply invert the default guess for .h files and assume they are C++ header files. But IIRC we didn't do this the past because e.g. for Geany's development itself it's more convenient to have .h files by default opened as C, see the auto completion symbol list problem above.
Then there is a piece of hard code which disables filetype commands for *.h* files. This can become rather messy when new commands are saved by filetype since we can't save any for header files.
Not sure why that's a problem.
Me too. At least it worked in the past and there is probably a solution/alternative to splitting up filetypes. I'm afraid this could end up in many more splits for other filetypes with multiple file extensions.
I propose that header files become first class citizens and be given their own filetypes with specific highlighting and commands. Detection will be
Why is this necessary? I would prefer not to do this.
Me neither. I was a little shocked when I saw this commit. We already have enough filetypes, I really don't see the need for splitting out C(+ +) headers as separate filetypes.
Regards, Enrico