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

[Lex Trotman]

>> Power users can always add *.h back to C types but I think having it in
>> C++ is a better default.
>>
>
> Yes you're only changing the default. I just stated my opionion and won't
> try to block the change. Go a head if you prefer.

Agree, I shouldn't be defending C programmers over C++ programmers,
although I support elimination of C++ coders who use .h for their
headers :)

>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Jiří Techet]

On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz  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.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Jiří Techet]

On Thu, Jan 7, 2016 at 11:14 PM, Lex Trotman  wrote:

> On 8 January 2016 at 08:00, Jiří Techet  wrote:
> >
> >
> > On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz 
> 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.
>

Fixed now.

Actually the tests "failed" because the tested files were C++ headers and
the previously-generated tags files were incorrect because of the used C
parser. So yeah, BEWARE USERS, HEADERS MIGHT BE PARSED CORRECTLY :-)

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Thomas Martitz]

Am 07.01.2016 um 23:00 schrieb Jiří Techet:



On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz > 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.




Yes you're only changing the default. I just stated my opionion and 
won't try to block the change. Go a head if you prefer.

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Matthew Brush]

On 2016-01-06 12:23 PM, Thomas Martitz 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.



Why is .h any more C than C++ or Obj-C? Because it came first? I agree 
it's stupid that in the later part of last millennium, they decided on 
the convention to use .h for C++ and Obj-C (and others?) headers since 
it was already a convention in C, but it did become a convention in C++ 
and now it's widely used, for example [0][1][2][3] among many, many others.


What's more, it's especially useful to see C++ keywords highlighted in 
.h header files, since they can be included in C++ as well as C[4][5][6] 
unless their author wants to make them less useful by using said 
keywords in the header. I think the most common case would be someone 
doing it inadvertently (as happened in Geany), which is where having 
them highlighted differently gives a visual queue that something is 
wrong[7].


Cheers,
Matthew Brush

[0]: https://git.gnome.org/browse/gtkmm/tree/gtk/gtkmm
[1]: https://github.com/qtproject/qtbase/tree/dev/src/corelib/global
[2]: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/files.html
[3]: http://sourceforge.net/p/scintilla/code/ci/default/tree/src/
[4]: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.h#n38
[5]: https://github.com/spurious/SDL-mirror/blob/master/include/SDL.h#L61
[6]: 
http://sourceware.org/git/?p=glibc.git;a=blob;f=include/stdlib.h;h=352339e8595eb8229018cb27f7d2decf63f511c7;hb=HEAD#l16
[7]: Or if the author is being evil on purpose, it gives them the smug 
satisfaction that they're making life hard for C++ programmers :)

___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Thomas Martitz]

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.


Best regards
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Colomban Wendling]

Oops, forgot the [1]

> 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.

[1] I mostly agree stock build commands are seldom (if ever) useful with
C and C++, but for the most basic "Hello World".  .o generation is even
less useful.
However, I do have a custom script (that fetches some deps by inspecting
includes) there I use to build very simple or test stuff, and it's very
handy in such cases.
But in all cases, we could imagine having many sorts of commands, maybe
a linter or anything; anyway not necessarily the same handling both C
and C++.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Matthew Brush]

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
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Lex Trotman]

I'm not sure about the combination, would have to examine it further.
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).

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.

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.

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.

Sadly a proposal that the Geany build system accommodate different
commands for different extensions, made during the last major build
system upgrade, was rejected as "too complicated".  And I'm not
interested in going back and adding it now, but would be happy to
advise anyone who wanted to do it.

I suggest that all of these issues should be examined together.

Cheers
Lex


On 29 December 2015 at 20:11, Matthew Brush  wrote:
> 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
>   - Special highlighting of C++ keywords so I know to avoid in C
>   - All C and C++ constructs always work
>   - No ambiguity of *.h files (except w/ Obj-C)
>
> 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)
>   - The default C++ extension wouldn't be suitable for plain C
>
> 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++
>
> 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.
>
> Cheers,
> Matthew Brush
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

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

[Lex Trotman]

On 29 December 2015 at 21:48, Matthew Brush  wrote:
> 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.

There is no reason why a C program can't use "template" or "throw" as
variables, its only a problem if they appear in external headers that
are used by C++.  Compiling it with C++ is the only reason that it
would be a problem, and why should that happen, its C!!! C is not C++,
as Colomban would say :)

>
>> 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++.

No, they are not much use to you and I, but they are for beginners,
and beginners are the very people who can't be expected to configure
stuff on day one.  Or write makefiles. So the default commands should
exist, and be safe.

>
>> 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.

Actually it doesn't include Geany, Geany only saves the current file,
not any other changed files.  Thats something else that was suggested
previously, and rejected.

> 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").

Indeed, thats what I said above, its easy to do by accident.  And when
its done by accident the PCH is not expected, so its tends to take
some time to find the problem.

>
>> 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
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel