[Geany-Devel] RFC: Merge C and C++ Filetypes (no troll)

[Colomban Wendling]

Le 29/12/2015 11:11, Matthew Brush a écrit :
> Hi,
> 
> I have been using Geany without the C filetype and opening all C files
> as C++. I use about 50% each of C and C++, and since I merged the two
> filetypes quite a few of headaches went away.
> 
> Some of the benefits:
> 
>   - C or C++ tags always work

This is a bug in current code that I think Jiří fixed in his scope PR.
But yeah, that's a fairly good point.

>   - Special highlighting of C++ keywords so I know to avoid in C
>   - All C and C++ constructs always work

I can understand this being useful in headers, really less in source
files, and as some I find this being some arbitrary C++ leaking into C

>   - No ambiguity of *.h files (except w/ Obj-C)

If only C++ people used some *meaningful* extensions, like .hpp or .hh…
Anyway, yeah, maybe for headers it could have a reasonable benefit to
warrant some weirdy things.  I sure got my share of C++ headers opened
as C annoying me -- to the point I got a slight look at allowing
extension patterns to include some path portion so I could force C++ for
some known locations.

BTW, IIRC currently creating a custom "C Header" filetype has some
drawbacks, because it's not recognized as C by CTags, because we used
the filetype's ID instead of the parser's ID to determine some logic or
something; but again it's something that should be fixed, and again IIRC
Jiří's scope PR takes care of this too.

> Some of the drawbacks:
> 
>   - Using C++ build commands for C doesn't make much sense
>       (although some claim compiling plain C as C++ to be a virtue)

(but they are wrong and simply try to shove some C++ down honest C
programmer's throats, so let's ignore them :))

>   - The default C++ extension wouldn't be suitable for plain C

Indeed that would be a problem.  Here again having a "C Header" filetype
highlighting C++ stuff would solve it  (once the other bugs are fixed).

> Some non-issues (AFAICT):
>   - Both filetypes already use the same Scintilla C++ lexer
>   - For Geany's purposes the CTags C++ parser works for both C and C++

I would indeed believe that CTags should mostly be fine parsing C as
C++, but when the C code is using C++ keywords as identifiers (i.e.
function `void template(void) {}` does't parse as C++).  Again, this
*might* be fine for headers, but maybe less for sources.

Sure, using C++ keywords as identifiers for C generally doesn't give
much, but failing on them is not really a great idea either: some people
do use them (heck, we used to), and disallowing them is a bit of an
arbitrary decision from us.

> It might be useful to only have one filetype for both. I'm content
> editing my config files locally, but I just thought it worth discussing
> to see if I'm mistaken on the perceived benefits/drawbacks.

It's indeed at least interesting to consider, because at least for .h
headers there really is some mixed stuff all over the place -- even,
simply look in Scintilla's source tree.

However, it being for build commands [1], or default extension, etc.,
I'm not sure having one single "C and C++ headers and sources" is a
great idea.
But maybe fixing all the bits and having 4 (!) filetypes (C, C header,
C++ and C++ header), and handling C headers as if they were C++ could be
a good idea to try out.  It would please Lex as he could get the header
build commands empty, we could keep default extension and build
commands, C++ headers with .h extensions would work as expected, and I
wouldn't expect much breakage because of using a C++ parser for C headers.


Regards,
Colomban