On 8 January 2016 at 08:00, Jiří Techet <techet@gmail.com> wrote:
>
>
> On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz <kugel@rockbox.org> wrote:
>>
>> Am 06.01.2016 um 21:12 schrieb Jiří Techet:
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>> +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).
>>>
>>>
>>
>> Not replying to Jiří specifically.
>>
>> -1. .h is legitimately a C, it's just that many people get it wrong. And I
>> don't want C++ keywords highlighted in C headers while they are not
>> highlighted it C source files. This is just confusing.
>
>
> I agree with Matthew here - I think the "damage" caused by parsing C headers
> with the C++ parser/lexer is much smaller than vice versa. Actually a few
> months back a user of my ProjectOrganizer plugin wrote me just because of
> that - he had a C++ project with "h" headers and was surprised that tag
> generation didn't work for him.
>
> I created (a highly sophisticated) pull request here:
>
> https://github.com/geany/geany/pull/857
>
> Power users can always add *.h back to C types but I think having it in C++
> is a better default.

As the failing tests show, better have a BIG warning about breaking
change if we do this.