<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 2, 2016 at 7:39 PM, Colomban Wendling <span dir="ltr"><<a href="mailto:lists.ban@herbesfolles.org" target="_blank">lists.ban@herbesfolles.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le 29/12/2015 11:11, Matthew Brush a écrit :<br>
> Hi,<br>
><br>
> I have been using Geany without the C filetype and opening all C files<br>
> as C++. I use about 50% each of C and C++, and since I merged the two<br>
> filetypes quite a few of headaches went away.<br>
><br>
> Some of the benefits:<br>
><br>
>   - C or C++ tags always work<br>
<br>
</span>This is a bug in current code that I think Jiří fixed in his scope PR.<br>
But yeah, that's a fairly good point.<br>
<span class=""><br>
>   - Special highlighting of C++ keywords so I know to avoid in C<br>
>   - All C and C++ constructs always work<br>
<br>
</span>I can understand this being useful in headers, really less in source<br>
files, and as some I find this being some arbitrary C++ leaking into C<br>
<span class=""><br>
>   - No ambiguity of *.h files (except w/ Obj-C)<br>
<br>
</span>If only C++ people used some *meaningful* extensions, like .hpp or .hh…<br>
Anyway, yeah, maybe for headers it could have a reasonable benefit to<br>
warrant some weirdy things.  I sure got my share of C++ headers opened<br>
as C annoying me -- to the point I got a slight look at allowing<br>
extension patterns to include some path portion so I could force C++ for<br>
some known locations.<br>
<br>
BTW, IIRC currently creating a custom "C Header" filetype has some<br>
drawbacks, because it's not recognized as C by CTags, because we used<br>
the filetype's ID instead of the parser's ID to determine some logic or<br>
something; but again it's something that should be fixed, and again IIRC<br>
Jiří's scope PR takes care of this too.<br>
<span class=""><br>
> Some of the drawbacks:<br>
><br>
>   - Using C++ build commands for C doesn't make much sense<br>
>       (although some claim compiling plain C as C++ to be a virtue)<br>
<br>
</span>(but they are wrong and simply try to shove some C++ down honest C<br>
programmer's throats, so let's ignore them :))<br>
<span class=""><br>
>   - The default C++ extension wouldn't be suitable for plain C<br>
<br>
</span>Indeed that would be a problem.  Here again having a "C Header" filetype<br>
highlighting C++ stuff would solve it  (once the other bugs are fixed).<br>
<span class=""><br>
> Some non-issues (AFAICT):<br>
>   - Both filetypes already use the same Scintilla C++ lexer<br>
>   - For Geany's purposes the CTags C++ parser works for both C and C++<br>
<br>
</span>I would indeed believe that CTags should mostly be fine parsing C as<br>
C++, but when the C code is using C++ keywords as identifiers (i.e.<br>
function `void template(void) {}` does't parse as C++).  Again, this<br>
*might* be fine for headers, but maybe less for sources.<br>
<br>
Sure, using C++ keywords as identifiers for C generally doesn't give<br>
much, but failing on them is not really a great idea either: some people<br>
do use them (heck, we used to), and disallowing them is a bit of an<br>
arbitrary decision from us.<br>
<span class=""><br>
> It might be useful to only have one filetype for both. I'm content<br>
> editing my config files locally, but I just thought it worth discussing<br>
> to see if I'm mistaken on the perceived benefits/drawbacks.<br>
<br>
</span>It's indeed at least interesting to consider, because at least for .h<br>
headers there really is some mixed stuff all over the place -- even,<br>
simply look in Scintilla's source tree.</blockquote><div><br></div><div>+1 for having the headers parsed/lexed by the C++ parser (with sources it may be a bit dangerous and typically the sources have the right C++ extension).</div><div><br></div><div>Jiri </div></div></div></div>