I have committed a prototype of the first part of the changes proposed for the build system to the build system branch. Since the manual on the branch still describes the full functionality we have been talking about, here is a short summary of what this commit can do. It could stand alone as a minimal set of changes if further functionality proves too difficult or controversial.
If no project is open everything should look, feel and operate as normal except the "Set Arguments and Includes" item in the build menu is now called "Set Build Menu Commands". The dialog is still the same if no project is open.
If a project is open the dialog will have extra fields to provide labels and commands to replace the "Make" series of menu items on the build menu. On the menu any label or command which is not set will revert to the default (the same as without any project). By default no labels or commands are set in the project file, so unless the user does something (sets them) there will be no change. These labels and commands are saved and restored with the project file.
Note when using commands set in the project file, the "make" command path in tools preferences is not used so that each command can have a different path. Therefore the command entered in the "Set Build Menu Commands" dialog must include any path it requires. Any command that reverts to default will still use the "make" command path so that it operates as usual.
At the moment there is no way to reset project commands to default without hand editing the project file.Setting them to blank does just that, it doesn't reset to default. A "reset to default" button will be added.
Having gotten some more experience I am in the process of updating the manual describing the full functionality some more to better describe how it should operate.
Best Regards Lex
On Fri, 17 Oct 2008 19:30:03 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hi,
I have committed a prototype of the first part of the changes proposed for the build system to
cool. But sorry, I won't have a look at it until next week, 0.15 release is just more important right now :).
Anyway, did you receive any bounce mail from Sourceforge about this commit? This commit again didn't generate a commit mail as it also happened (again) to me today. Sourceforge staff told they have fixed these problems, obviously they didn't.
Regards, Enrico
On Sat, Oct 18, 2008 at 12:11 AM, Enrico Tröger enrico.troeger@uvena.dewrote:
On Fri, 17 Oct 2008 19:30:03 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hi,
I have committed a prototype of the first part of the changes proposed for the build system to
cool. But sorry, I won't have a look at it until next week, 0.15 release is just more important right now :).
Of course, when you can.
Anyway, did you receive any bounce mail from Sourceforge about this commit? This commit again didn't generate a commit mail as it also happened (again) to me today. Sourceforge staff told they have fixed these problems, obviously they didn't.
No I ddin't get any email
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi, Sorry for the delay. (As I said in another mail, my net connection was broken for 2 weeks.)
On Fri, 17 Oct 2008 19:30:03 +1100 "Lex Trotman" elextr@gmail.com wrote:
I have committed a prototype of the first part of the changes proposed for the build system to the build system branch.
Cool. I just made some minor commits to fix a warning and refactor some GUI code.
BTW there are some formatting issues: 1. Some spaces instead of tabs being used for indentation (e.g. in build.c). 2. Spacing - instead of:
if( blah!=foo )some_func( foo );
use:
if (blah != foo) some_func(foo);
Please use the existing code style (see HACKING).
The indentation is the most important one, could you fix this please?
About the code: 1. No real need to check if ptr is null before g_free(ptr).
2. I think we should move the new build_* GeanyProject fields to a GeanyProjectPrivate struct, similar to GeanyDocumentPrivate/GeanyFiletypePrivate. The implementation of those fields might change, so they shouldn't be in the plugin API. I can make this change unless someone disagrees.
If a project is open the dialog will have extra fields to provide labels and commands to replace the "Make" series of menu items on the build menu.
(I guess replacing the make menu items is not implemented yet.)
On the menu any label or command which is not set will revert to the default (the same as without any project). By default no labels or commands are set in the project file, so unless the user does something (sets them) there will be no change. These labels and commands are saved and restored with the project file.
Maybe by default they should be set to the default make command labels and commands. Otherwise the dialog is unintuitive - just empty boxes.
Note when using commands set in the project file, the "make" command path in tools preferences is not used so that each command can have a different path. Therefore the command entered in the "Set Build Menu Commands" dialog must include any path it requires. Any command that reverts to default will still use the "make" command path so that it operates as usual.
OK.
At the moment there is no way to reset project commands to default without hand editing the project file.Setting them to blank does just that, it doesn't reset to default. A "reset to default" button will be added.
Hmm, why not just use the default if they're blank?
Regards, Nick
2008/11/6 Nick Treleaven nick.treleaven@btinternet.com
Hi, Sorry for the delay. (As I said in another mail, my net connection was broken for 2 weeks.)
On Fri, 17 Oct 2008 19:30:03 +1100 "Lex Trotman" elextr@gmail.com wrote:
I have committed a prototype of the first part of the changes proposed for the build system to the build system branch.
Cool. I just made some minor commits to fix a warning and refactor some GUI code.
Ok, warning that this is still a prototype, GUI code is still being changed to get the full functionality shown in the geany.txt I committed recently.
BTW there are some formatting issues:
- Some spaces instead of tabs being used for indentation (e.g. in
build.c). 2. Spacing - instead of:
if( blah!=foo )some_func( foo );
use:
if (blah != foo) some_func(foo);
Please use the existing code style (see HACKING).
Do you have a configuration for one of the usual source formatters to get the format you want, I AM going to continue to get it wrong because it is different to the standard format I use all day every day at work. The fingers just automatically put spaces on the other side of the ( ) etc. Even if I'm thinking about it, it will get done wrong from time to time ;-). You are correct that it should be consistent within Geany so if there is a formatter that will generate the format used throughout Geany I will ensure that I use it.
The indentation is the most important one, could you fix this please?
Well, all editing has been done in Geany with indentation set to tabs so I don't know where the problem came from??? but I can fix it.
About the code:
- No real need to check if ptr is null before g_free(ptr).
Ok
- I think we should move the new build_* GeanyProject fields to a
GeanyProjectPrivate struct, similar to GeanyDocumentPrivate/GeanyFiletypePrivate. The implementation of those fields might change, so they shouldn't be in the plugin API. I can make this change unless someone disagrees.
Don't worry, I'll do that because I have already made some changes in that area to support the full functionality. No point in doing it on the prototype when there are more changes to come.
If a project is open the dialog will have extra fields to provide labels and commands to replace the "Make" series of menu items on the build menu.
(I guess replacing the make menu items is not implemented yet.)
Did you have a project open? the prototype only adds these items to the menu or the build commands dialog when a project is open. The full version will also show them for preferences which isn't implemented in this version. Coming real soon now though :-) maybe [?]
And underscores in the user defined labels will set the accelerator correctly too.
On the menu any label or command which is not set will revert to the default (the same as without any project). By default no labels or commands are set in the project file, so unless the user does something (sets them) there will be no change. These labels and commands are saved and restored with the project file.
Maybe by default they should be set to the default make command labels and commands. Otherwise the dialog is unintuitive - just empty boxes.
The full version will work that way, see the manual. Note these are generated if there is nothing saved in the project or preferences. That way the menu label strings are translated like any string is. It is assumed that when a user edits a label they will do it in the language they want and so no translation is needed for the label saved in project or preferences, but it is important that there is no default value saved that isn't translated.
Note when using commands set in the project file, the "make" command path in tools preferences is not used so that each command can have a different path. Therefore the command entered in the "Set Build Menu Commands" dialog must include any path it requires. Any command that reverts to default will still use the "make" command path so that it operates as usual.
OK.
At the moment there is no way to reset project commands to default without hand editing the project file.Setting them to blank does just that, it doesn't reset to default. A "reset to default" button will be added.
Hmm, why not just use the default if they're blank?
Because in the full version blank means don't show this menu item, this makes the build commands operate the same as the filetype commands which do not show unused commands.
NOTE: this brings up one significant change needed for the full version, the can compile, can build, flags of the filetype will no longer be used since the existance (or not) of such a command is what determines if a menu item is shown. Otherwise users would not be able to add filetype commands to unused filetype menu items. So in the full version, a commandwhich is not set will mean use the default whilst one set to nothing (item name) will mean don't use. Have to allow 'command set to nothing' just in case someone wants to use the make custom dialog to type the whole command, possibly useful for occasionally used commands whilst still capturing and parsing the command output.
But are there any other important uses of these flags besides controlling what is shown in the build menu?
Best Regards Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 6 Nov 2008 21:06:09 +1100 Lex Trotman elextr@gmail.com wrote:
Cool. I just made some minor commits to fix a warning and refactor some GUI code.
Ok, warning that this is still a prototype, GUI code is still being changed to get the full functionality shown in the geany.txt I committed recently.
OK, I'll look at the manual changes hopefully today. The small change was just for code organization.
BTW, you can commit code that doesn't build, or work-in-progress, no need to wait until it's ready to test, if you have a lot of changes in your working copy.
BTW there are some formatting issues:
- Some spaces instead of tabs being used for indentation (e.g. in
build.c). 2. Spacing - instead of:
if( blah!=foo )some_func( foo );
use:
if (blah != foo) some_func(foo);
Please use the existing code style (see HACKING).
Do you have a configuration for one of the usual source formatters to get the format you want, I AM going to continue to get it wrong because it is different to the standard format I use all day every day at work. The fingers just automatically put spaces on the other side of the ( ) etc. Even if I'm thinking about it, it will get done wrong from time to time ;-). You are correct that it should be consistent within Geany so if there is a formatter that will generate the format used throughout Geany I will ensure that I use it.
I haven't really tried them, I wrestled with GNU indent once but couldn't work out how to tell it to use tabs only. Probably there's a better formatter out there, but you'll have to play with the options to get a matching style.
The indentation is the most important one, could you fix this please?
Well, all editing has been done in Geany with indentation set to tabs so I don't know where the problem came from??? but I can fix it.
Somehow your commit has introduced them, they weren't there before in build.c (and elsewhere). Try seaching with the regex "^\t* +" (note the 2 spaces to prevent matches for multiline comments).
There will be a few matches for Glade callback argument alignment, but other than these all lines should only use tabs.
Sorry to be pedantic ;-)
- I think we should move the new build_* GeanyProject fields to a
GeanyProjectPrivate struct, similar to GeanyDocumentPrivate/GeanyFiletypePrivate. The implementation of those fields might change, so they shouldn't be in the plugin API. I can make this change unless someone disagrees.
Don't worry, I'll do that because I have already made some changes in that area to support the full functionality. No point in doing it on the prototype when there are more changes to come.
OK, cool.
If a project is open the dialog will have extra fields to provide labels and commands to replace the "Make" series of menu items on the build menu.
(I guess replacing the make menu items is not implemented yet.)
Did you have a project open? the prototype only adds these items to the menu or the build commands dialog when a project is open. The
Yes, I set 2 project build commands, then checked the menu. It doesn't work after updating the dialog, but reopening the project does work.
BTW there was a bug where the 3rd project build menu item is created based on the 2nd label.
full version will also show them for preferences which isn't implemented in this version. Coming real soon now though :-) maybe [?]
Not quite sure what you mean, but I'll read the manual changes first.
...
Maybe by default they should be set to the default make command labels and commands. Otherwise the dialog is unintuitive - just empty boxes.
The full version will work that way, see the manual. Note these are generated if there is nothing saved in the project or preferences. That way the menu label strings are translated like any string is. It is assumed that when a user edits a label they will do it in the language they want and so no translation is needed for the label saved in project or preferences, but it is important that there is no default value saved that isn't translated.
Sounds good.
...
At the moment there is no way to reset project commands to default without hand editing the project file.Setting them to blank does just that, it doesn't reset to default. A "reset to default" button will be added.
Hmm, why not just use the default if they're blank?
Because in the full version blank means don't show this menu item, this makes the build commands operate the same as the filetype commands which do not show unused commands.
OK. Maybe a checkbox to enable them, on by default, might be better. But no need to implement this.
NOTE: this brings up one significant change needed for the full version, the can compile, can build, flags of the filetype will no longer be used since the existance (or not) of such a command is what determines if a menu item is shown. Otherwise users would not be
I agree, I wanted to remove them before.
able to add filetype commands to unused filetype menu items. So in the full version, a commandwhich is not set will mean use the default whilst one set to nothing (item name) will mean don't use. Have to allow 'command set to nothing' just in case someone wants to use the make custom dialog to type the whole command, possibly useful for occasionally used commands whilst still capturing and parsing the command output.
But are there any other important uses of these flags besides controlling what is shown in the build menu?
If so, they can be replaced with if (NZV(ft_command_str)) checks (or maybe just checks against null for the custom command).
Regards, Nick
2008/11/7 Nick Treleaven nick.treleaven@btinternet.com
BTW there are some formatting issues:
- Some spaces instead of tabs being used for indentation (e.g. in
build.c). 2. Spacing - instead of:
if( blah!=foo )some_func( foo );
use:
if (blah != foo) some_func(foo);
Please use the existing code style (see HACKING).
Do you have a configuration for one of the usual source formatters to get the format you want, I AM going to continue to get it wrong because it is different to the standard format I use all day every day at work. The fingers just automatically put spaces on the other side of the ( ) etc. Even if I'm thinking about it, it will get done wrong from time to time ;-). You are correct that it should be consistent within Geany so if there is a formatter that will generate the format used throughout Geany I will ensure that I use it.
I haven't really tried them, I wrestled with GNU indent once but couldn't work out how to tell it to use tabs only. Probably there's a better formatter out there, but you'll have to play with the options to get a matching style.
The indentation is the most important one, could you fix this please?
Well, all editing has been done in Geany with indentation set to tabs so I don't know where the problem came from??? but I can fix it.
Somehow your commit has introduced them, they weren't there before in build.c (and elsewhere). Try seaching with the regex "^\t* +" (note the 2 spaces to prevent matches for multiline comments).
There will be a few matches for Glade callback argument alignment, but other than these all lines should only use tabs.
Sorry to be pedantic ;-)
No problem, it is more important that a project chooses and sticks to a
style than what the style actually is. On the other hand formatting is the sort of rote activity that I believe computers should do, not people. On that basis my work experience student now knows much more than she ever wanted to about C code formatters. We have found one, 'uncrustify' that seems to do what we want without doing too much extra, I have committed a version of build.c run through it for you to have a look at. uncrustify is very flexible (about 250-300 options) and it seems to be able to enforce all the requirements of HACKING. The only extra things that I can't stop it doing are: - positioning the alignment of variable definitions and parameters slightly different to the originals (still aligns and hangs * though) - aligning function call continuations with the open parens, I think it is ok, see what you think. It can cause the call to need more wrapping though.
The wrapping of long lines is a little simplistic for long function calls that are already manually wrapped, needs a bit of a helping hand but not very often.
PS thanks for the hint about meld you gave in a previous email, made comparing formatted and unformatted versions very easy.
Yes, I set 2 project build commands, then checked the menu. It doesn't work after updating the dialog, but reopening the project does work.
interesting, will look at it, I thought I called update_menu everywhere I needed, but must have missed somewhere
BTW there was a bug where the 3rd project build menu item is created based on the 2nd label.
Ah yes, the old copy and paste and forget to edit the names trick ;-) will fix
full version will also show them for preferences which isn't implemented in this version. Coming real soon now though :-) maybe [?]
What I meant was that in the full version build (ie make) commands come from project, user prefs or default whichever is found first. It is partly implemented, so of course like all software its gonna be finished "real soon now"
Not quite sure what you mean, but I'll read the manual changes first.
OK. Maybe a checkbox to enable them, on by default, might be better. But no need to implement this.
I guess its a choice between ways of skinning the cat, having a checkbox would allow users to show blank menu items, whilst having blanks hide items needs clear documentation. Given that the target users are programmers, I think either would be ok, I am sure that if they are up to the level of changing the commands, they would be capable of fiddling with the settings to get what they want, whichever way it worked. I'll continue on the current path for now but I don't have any strong feelings either way.
NOTE: this brings up one significant change needed for the full version, the can compile, can build, flags of the filetype will no longer be used since the existance (or not) of such a command is what determines if a menu item is shown. Otherwise users would not be
I agree, I wanted to remove them before.
able to add filetype commands to unused filetype menu items. So in the full version, a commandwhich is not set will mean use the default whilst one set to nothing (item name) will mean don't use. Have to allow 'command set to nothing' just in case someone wants to use the make custom dialog to type the whole command, possibly useful for occasionally used commands whilst still capturing and parsing the command output.
But are there any other important uses of these flags besides controlling what is shown in the build menu?
If so, they can be replaced with if (NZV(ft_command_str)) checks (or maybe just checks against null for the custom command).
Ok, i'll take that as removal is ok
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Cheers Lex
2008/11/7 Lex Trotman elextr@gmail.com
2008/11/7 Nick Treleaven nick.treleaven@btinternet.com
Yes, I set 2 project build commands, then checked the menu. It doesn't
work after updating the dialog, but reopening the project does work.
interesting, will look at it, I thought I called update_menu everywhere I needed, but must have missed somewhere
Hopefully fixed now
BTW there was a bug where the 3rd project build menu item is created based on the 2nd label.
Ah yes, the old copy and paste and forget to edit the names trick ;-) will fix
Fixed
In planning my attack on the next phase I have come to the point where I have to to raise something I am sure has been raised before, C & C++ header filetypes. 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). 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.
I propose that header files become first class citizens and be given their own filetypes with specific highlighting and commands. Detection will be easy for distinct extensions such as .hpp etc but not all compilers seem to properly support them (aside: the C++ standard can be read as only *requiring* support for a single character after the dot though not preventing multi character extensions). For .h or unnamed files I suggest extending filetypes_detect_from_file_internal() that looks for shebangs to look for "C++" anywhere in line one. This will detect the emacs -*-C++-*- sequence or similar. On my system at least, all the C++ standard header files have this since most do *not* have any extension (eg <iostream>) and many C++ application libraries have them too. So this seems a reasonable approach and will of course assist Geany's replacement of Emacs as "all the worlds programmers favourite editor" ;-) For default commands for header files I propose just a compile that does a syntax check, since I seem to spend as long getting compile errors out of headers as I do bodies, making them compile before I use them would be helpful. This of course requires different commands for C++ and C so they need to be different filetypes.
Have I missed some key reason for not having distinct C and C++ header filetypes (other than the detection issue)??
In reaching the above understanding I noticed that filetype.c has 'class' in its keywords, this isn't a C keyword.
Cheers Lex
Hi,
As a followup to the suggestion below I have committed a prototype of filetypes for C and C++ headers to the build_system branch. The filetype detection also checks .h and no extension files for -*-C++-*- in line one to indicate a C++ header. Just to be annoying the C++ standard headers (as distinct from the C++ versions of the C headers which is what I looked at before) use -*- C++ -*- (extra spaces) and according to the Emacs manual there is much which can go in between the -*- es so I think I might have to look for C++ anywhere between the -*- es. Or fall back to my original idea of C++ anywhere on the line at the risk of comments which just happen to contain C++ triggering the filetype. Admittedly this risk is small as the search is only performed on .h or no extension files. I will think about it some more.
In the meantime since adding filetypes seems to be entwined in lots of areas any suggestions of things I may have missed in terms of adding these filetypes would be appreciated.
Cheers Lex
2008/11/10 Lex Trotman elextr@gmail.com
2008/11/7 Lex Trotman elextr@gmail.com
2008/11/7 Nick Treleaven nick.treleaven@btinternet.com
Yes, I set 2 project build commands, then checked the menu. It doesn't
work after updating the dialog, but reopening the project does work.
interesting, will look at it, I thought I called update_menu everywhere I needed, but must have missed somewhere
Hopefully fixed now
BTW there was a bug where the 3rd project build menu item is created based on the 2nd label.
Ah yes, the old copy and paste and forget to edit the names trick ;-) will fix
Fixed
In planning my attack on the next phase I have come to the point where I have to to raise something I am sure has been raised before, C & C++ header filetypes. 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). 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.
I propose that header files become first class citizens and be given their own filetypes with specific highlighting and commands. Detection will be easy for distinct extensions such as .hpp etc but not all compilers seem to properly support them (aside: the C++ standard can be read as only *requiring* support for a single character after the dot though not preventing multi character extensions). For .h or unnamed files I suggest extending filetypes_detect_from_file_internal() that looks for shebangs to look for "C++" anywhere in line one. This will detect the emacs -*-C++-*- sequence or similar. On my system at least, all the C++ standard header files have this since most do *not* have any extension (eg <iostream>) and many C++ application libraries have them too. So this seems a reasonable approach and will of course assist Geany's replacement of Emacs as "all the worlds programmers favourite editor" ;-) For default commands for header files I propose just a compile that does a syntax check, since I seem to spend as long getting compile errors out of headers as I do bodies, making them compile before I use them would be helpful. This of course requires different commands for C++ and C so they need to be different filetypes.
Have I missed some key reason for not having distinct C and C++ header filetypes (other than the detection issue)??
In reaching the above understanding I noticed that filetype.c has 'class' in its keywords, this isn't a C keyword.
Cheers Lex
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++.
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.
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.
Regards, Nick
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
On Mon, 10 Nov 2008 17:53:57 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
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.
Yes, I forgot about that.
Lex: C++ filetypes can see C symbol tags, but not vice versa, so we assume *.h is a C file. But if there is some semi-standard magic string detection for marking *.h as C++, that would be fine to implement (as you mentioned).
Regards, Nick
On Mon, 10 Nov 2008 14:10:04 +1100, "Lex Trotman" elextr@gmail.com wrote:
filetypes_detect_from_file_internal() that looks for shebangs to look for "C++" anywhere in line one. This will detect the emacs -*-C++-*- sequence or similar. On my system at least, all the C++ standard
I'm not completely happy with this but if we can limit this check to the first or the first both lines it might be worth. But I think we shouldn't do much more to guess a C++ file. Especially for the C++ includes without file extensions, it's simply hard to detect them and users should understand that there are limits (remember, the more we guess, the slower gets the whole file opening process).
compile that does a syntax check, since I seem to spend as long getting compile errors out of headers as I do bodies, making them compile before I use them would be helpful. This of course requires different commands for C++ and C so they need to be different filetypes.
Wow, is it really necessary to be able to compile header files? I don't see the advantage as you get the same compiler errors and warning in header files when compiling one of the source files which include them.
In reaching the above understanding I noticed that filetype.c has 'class' in its keywords, this isn't a C keyword.
Thanks for the pointer, this is indeed wrong as well as 'new' and 'delete' which also are C++ only keywords. I'll remove those later.
Regards, Enrico
On Mon, 10 Nov 2008 18:08:09 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
compile that does a syntax check, since I seem to spend as long getting compile errors out of headers as I do bodies, making them compile before I use them would be helpful. This of course requires different commands for C++ and C so they need to be different filetypes.
Wow, is it really necessary to be able to compile header files? I don't see the advantage as you get the same compiler errors and warning in header files when compiling one of the source files which include them.
Maybe the user can use Make Object to compile header files, or (if implemented) an extra filetype command, not the C compile command, which should be for source files by default.
I don't think we should add C/C++ header filetypes just to avoid implementing extra filetype command support. This would apply for other filetypes too.
Regards, Nick
Hi Guys,
I thought the suggestion of having separate header file types would be controversial ;-), otherwise it would have been done by now.
Let me run through a couple of points about C++ headers and why they need full support as much as possible.
C++ headers are potentially much more complex than C ones with templates and inline functions in them. So not having language support is significant. The C++ application I am working on (and which first got me using Geany before I introduced it at work) has only medium complex templates but I still spend as much time getting the .h file to compile as the .cpp file. And thats without things such as template metaprogramming, which is code written to run at compile time in headers. As an example, the boost C++ libraries contain lots of complex functionality of which 75% is purely in headers without any supporting body, so lots of work gets done at compile time not at runtime, so its faster, but it makes the headers much more complex. I think the best example is the sprint library that is a complete parser that does all the stuff bison does at compile time and in the .h files.
The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important. So is compiling .h files independently, it is annoying having to pick through errors in the .cpp file (often caused by errors in the .h file) to find the .h errors and fix them first, usually it gets so complex that errors get fixed only a few at a time. It would be much easier to get the .h to compile first. And on gcc at least, that can leave a pre-compiled header that would speed up further uses of that header.
Now despite all that, I agree with Enrico that the default should be that .h is C, thats the historical use and it fits with Geany development.
The marking -*-C++-*- exists on all GNU headers which means it should be present on most Linuxii, I don't know about windows though. Looking at other (non-system) library headers I've got available, most of the C++ .h files identify themselves and interestingly about 15% of the C .h files identify themselves as C. In terms of the delays in opening the file, it is only intended to look at line 1 which has already been examined for shebang so it is already available in memory, most of the overhead has already occurred. Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have these separate .h .hpp templates irrespective of the end result of these discussions because creating headers using C or C++ templates and filenames means you need to delete the main you don't want, add the guards etc.and then change the file extension on save too.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could be arranged to support compilation of .h files for syntax purposes only, without it doing them every build because there is no output file, I suppose separate targets that do not run into the main build could work but I'm not sure how that sits with autotools.
I can understand your concern about flow on effects with other languages, unfortunately I don't know enough of them to contribute to a discussion of if the same problem as .h occurs or if there are other differences between headers and bodies that makes separate filetypes beneficial.
I did a quick survey of how other tools approach this problem (both IDEs and just editors), 1. Emacs - templates are manual, uses extension or -*- to separate C & C++ 2. Anjuta - separate templates for C and C++ headers and body, treats .h as C++ for highlighting, autocomplete doesn't work for keywords 3. gedit - doesn't have templates, .h as C++, no autocompletion 4. kate - can't tell because documentation on website didn't work, but see kdevelop 5. kdevelop - separate templates for C and C++ headers and bodies, .h highlights as C++, don't know about autocompletion (too many 'not written yet' in the manual and I'm not going to install it just for this)
Not much help really...:-P
In summary my judgement is that C++ users (me, I'm not claiming to be unbiased) would gain significantly by having proper header file support and C users much less. And I don't see that either user community loses anything.
The commit of the prototype yesterday was the result of me trying to find out just what is involved, by the time I'd found out, I'd done it (at least I think so). By doing it as a separate commit without any other changes you can look at it and it can be bypassed if I stuffed it up too bad.
I have to continue to propose that this is a worthwhile change, please consider it further.
Best Regards Lex
On Tue, 11 Nov 2008 14:26:39 +1100 "Lex Trotman" elextr@gmail.com wrote:
C++ headers are potentially much more complex than C ones with templates and inline functions in them. So not having language support is significant. The C++ application I am working on (and
C++ headers are not a separate language from C++ source files, they are the same language. Same for C headers.
The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important. So is
Agreed, the first line detection would be a good feature.
Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have
I don't think we should encourage people to make C++ header files with a .h extension, they should use an extension unique to C++.
BTW with custom file templates you can have as many templates as you like for the same filetype, so you could have header.hpp, source.cpp, etc template files.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could
I meant when you have a foo.h file and a foo.c file, you can use Make Object on the foo.h file.
When you only have a foo.h file, this is where having custom filetype commands would be helpful - either a command to compile the header or a syntax check command. (This could also be a project command).
I can understand your concern about flow on effects with other languages, unfortunately I don't know enough of them to contribute to
There could be special files for some languages that require different build commands, but if they are the same language they should not have a separate filetype. This is a build command issue, not a filetype one.
In summary my judgement is that C++ users (me, I'm not claiming to be unbiased) would gain significantly by having proper header file support and C users much less. And I don't see that either user community loses anything.
This would cause more code to maintain, and more checks for header filetypes as well as the source file filetypes.
Regards, Nick
Hi Guys,
Having taken the luxury of an uninterupted day to think about it I think Nick and Enrico combined have defined the problem: I've combined responses to both below.
Nick: C++ headers are not a separate language from C++ source files, they are the same language. Same for C headers. There could be special files for some languages that require different build commands, but if they are the same language they should not have a separate filetype. This is a build command issue, not a filetype one.
Enrico: As Nick already said, this is a build command issue. With the current code, one solution could be to remove the limitation that headers files can't be compiled. Anyway, there should be really no need for separate header filetypes. And since you are currently about to rework the build system, just make the custom filetype build commands work with header files.
To summarise the problem in very few words, we have files that contain the same language but require different actions. The table below defines it for C/C++ (hope it comes through the email neatly)
Semantics Language Extension Actions
C header C .h compile no .o file
C source C .c compile, link, run
C++ header C++ .h & mark compile no .o file .hpp .hxx etc
C++ source C++ .cpp .cxx compile, link, run etc
In the current implementation Geany does not have any way of distinguishing the language in the file (used for highlighting and symbols) from the semantics (used for the actions/commands allowed on the file).
From the discussions to date the solutions seem to be:
1. My solution was to define new filetypes (which use the same language internally) so I got separate actions. I think its fair to say that your response is that this is way overkill for the purpose ;-) although I didn't think the actual implementation was that significant since it uses C and C++ language stuff for Scintilla and tagmanager.
2. Use the same commands for source and header. Since the compile commands are different between source and header, that means we have two compile commands at the same time which is a potential source of confusion & I think generally yucky.
3. Use custom commands, but we still have the two commands problem from the item above and this is something that Geany really should offer its users as standard, not requiring them to configure it.
4. Use project/user preference commands. Now unwanted commands are visible on all languages which is worse, and we have the same problem that it should be standard.
The other solution I have thought of so far is to actually implement separation of semantics and language, I havn't got an actual implementation but it probably isn't too difficult to have another field in GeanyFiletype to select from several sets of commands. With default behaviour it should be possible to keep filetypes.xxx backward compatible but they will expand (and do for build system anyway). This GeanyFiletype field would be set using the code in implementation 1. above. Using the correct commands would be part of the build system extension. This does remove some mucky hardcoding in switch statements in implementation 1. that makes headers behave the same as source for scintilla and tagmanager but I don't know what else it may add. I don't know if this should be visible to plug-ins, it could give them a way of manipulating commands and, although I can't immediately think of why, my instinct is to make it available, but that changes the API I think. Your call.
Any other suggestions welcome.
I have combined responses below to Nick and Enricos points not covered so far.
2008/11/11 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 11 Nov 2008 14:26:39 +1100 "Lex Trotman" elextr@gmail.com wrote:
Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have
I don't think we should encourage people to make C++ header files with a .h extension, they should use an extension unique to C++.
I entirely agree!! Unfortunately a couple of old compilers don't and there is lots of code out there using .h files. I blame Stroustrup, who only uses .h for headers throughout his book, even though he acknowledges .cpp .cxx etc.
BTW with custom file templates you can have as many templates as you like for the same filetype, so you could have header.hpp, source.cpp, etc template files.
Can those templates be delivered with Geany? For something fairly fundamental it shouldn't require every user to configure it.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could
I meant when you have a foo.h file and a foo.c file, you can use Make Object on the foo.h file.
I still don't understand how this compiles the .h only, sorry for being obtuse.
This would cause more code to maintain, and more checks for header filetypes as well as the source file filetypes.
Surprisingly little code, Geany is pretty well structured but there are some hacks needed where filetype checks are hard coded.
Regards, Nick
Hey,
The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important. So is compiling .h files independently, it is annoying having to pick through errors in the .cpp file (often caused by errors in the .h file) to find the .h errors and fix them first, usually it gets so
As Nick already said, this is a build command issue. With the current code, one solution could be to remove the limitation that headers files can't be compiled.
I assumed that this has to happen anyway.
I don't remember exactly why I added this but mainly because until this thread I was thinking compiling header files doesn't make any sense at all. Maybe there were other reasons, too. Anyway, there should be really no need for separate header filetypes. And since you are currently about to rework the build system, just make the custom filetype build commands work with header files.
As outlined above I need to know its a header file, thats the problem.
The marking -*-C++-*- exists on all GNU headers which means it should be present on most Linuxii, I don't know about windows though. Looking at other (non-system) library headers I've got available, most of the C++ .h files identify themselves and interestingly about 15% of the C .h files identify themselves as C. In terms of the delays in opening the file, it is only intended to look at line 1 which has already been examined for shebang so it is already available in memory, most of the overhead has already occurred. Having separate C+
Yup, this is why I said the check should work on the first line or the first both lines. Then it doesn't cause much more overhead than already existent.
We are in furious agreement here ;-)
- header templates with the mark already in it would help users to
remember to add it. BTW it would be good to have these separate .h .hpp templates irrespective of the end result of these discussions because creating headers using C or C++ templates and filenames means you need to delete the main you don't want, add the guards etc.and then change the file extension on save too.
Check the classbuilder plugin. It's not exactly the same but it creates C++ class files and the corresponding headers, including guards and all this stuff. Unfortunately, the used templates in the plugin are not (yet) configurable but this is an easy task, it just needs to be done. Alternatively, Nick already stated about custom file templates.
Sort of the thing but I was only suggesting a really simple minimal header template for both C and C++. Also now we have two places to create files from, the file new or toolbar or the tools->plugin menus. I don't see any documentation for classbuilder plugin either so I hadn't realised it might be useful.
- Show quoted text -
Regards, Enrico
Finally whilst testing I found what I think is a bug in C/C++ symbols in tagmanager, since it occurs on 0.15 will submit a normal bug report for it.
Cheers Lex
Just to reply to the quick points:
On Wed, 12 Nov 2008 14:23:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have
I don't think we should encourage people to make C++ header files with a .h extension, they should use an extension unique to C++.
I entirely agree!! Unfortunately a couple of old compilers don't and there is lots of code out there using .h files. I blame Stroustrup, who only uses .h for headers throughout his book, even though he acknowledges .cpp .cxx etc.
OK, but I don't think any default templates that come with Geany should need the C++ comment mark.
BTW with custom file templates you can have as many templates as you like for the same filetype, so you could have header.hpp, source.cpp, etc template files.
Can those templates be delivered with Geany? For something fairly fundamental it shouldn't require every user to configure it.
Basically this needs some work, but will get done some time. But the point is that custom file templates support is already implemented, so this isn't another reason to add header filetypes.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could
I meant when you have a foo.h file and a foo.c file, you can use Make Object on the foo.h file.
I still don't understand how this compiles the .h only, sorry for being obtuse.
It doesn't, it compiles the .o, but (when you have foo.c) it catches any errors in the header.
This would cause more code to maintain, and more checks for header filetypes as well as the source file filetypes.
Surprisingly little code, Geany is pretty well structured but there are some hacks needed where filetype checks are hard coded.
I think it is significantly more for maintenance/writing new features.
Regards, Nick
Nick, I was up late watching the late movie, so here's a quick agreement.
2008/11/13 Nick Treleaven nick.treleaven@btinternet.com
Just to reply to the quick points:
On Wed, 12 Nov 2008 14:23:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have
I don't think we should encourage people to make C++ header files with a .h extension, they should use an extension unique to C++.
I entirely agree!! Unfortunately a couple of old compilers don't and there is lots of code out there using .h files. I blame Stroustrup, who only uses .h for headers throughout his book, even though he acknowledges .cpp .cxx etc.
OK, but I don't think any default templates that come with Geany should need the C++ comment mark.
Yeah if the delivered header templates were only for .hpp they wouldn't need it. I guess the C++ mark just needs to be clearly documented for those cases where a C++ .h already exists or is forced by external circumstance. Saw your comment on removing filetype templates on another post, sounds like a clean solution. Delivering data files makes it easy for users to tinker and saves you code maintenance.
BTW with custom file templates you can have as many templates as you like for the same filetype, so you could have header.hpp, source.cpp, etc template files.
Can those templates be delivered with Geany? For something fairly fundamental it shouldn't require every user to configure it.
Basically this needs some work, but will get done some time. But the point is that custom file templates support is already implemented, so this isn't another reason to add header filetypes.
Of course not, templates is completely separate from the header file operation problem. Thats why I left it down here.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could
I meant when you have a foo.h file and a foo.c file, you can use Make Object on the foo.h file.
I still don't understand how this compiles the .h only, sorry for being obtuse.
It doesn't, it compiles the .o, but (when you have foo.c) it catches any errors in the header.
Oh, Ok, but then I get all the cascade errors in the .cpp file caused by the errors in the .hpp file, the idea is to compile the header first before using it. I need to do that not only on initial creation but on changes during debugging, adding functionality etc. Basically any time I modify the hpp file significantly. Lets see what we can come up with IRO the main question.
This would cause more code to maintain, and more checks for header filetypes as well as the source file filetypes.
Surprisingly little code, Geany is pretty well structured but there are some hacks needed where filetype checks are hard coded.
Take this comment as the complement it was meant to be. I am not intending to tell you how much work to take on as a maintainer.
I think it is significantly more for maintenance/writing new features.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Guys,
Further thoughts on how to allow variations on the commands associated with a filetype, I would propose having a concept of a variant of a filetype. This is just extra information determined from a subset of the filetypes extensions. It can be implemented fully configurable from the filetypes.xxx file so no hard coded magic. An extract of the extended filetypes.c below shows what I mean:
[settings] # list of the variants supported variants=hdrs
# definition of how the variant is detected, list of extension patterns [variants] hdrs=*.h
# default build settings for no variants [build_settings] compiler=gcc -Wall -c "%f" linker=gcc -Wall -o "%e" "%f" run_cmd="./%e"
# buld settings for variant hdrs [build_settings_hdrs] compiler=gcc -Wall -c "%f" # no linker or run for headers
This is backward compatible with existing filetypes .c because the default [build_settings] is still there and the same.
The document has a pointer to the variant information so the build menu can be set from it per file.
Attached is a patch against the build-system branch revision 3195 which was before header filetypes changes. It gives you an idea of the amount of code needed to set the variant commands, not too much really and fairly localised. Obviously saving/restoring and using them is part of the upcoming build system changes so the patch does nothing visible.
Other variants can be defined, which I suspect could be useful when some of the upcoming incompatible language changes hit eg python 3 & perl 6 so that commands can vary with dialect.
Cheers Lex
On Thu, 13 Nov 2008 19:39:43 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hi Guys,
Further thoughts on how to allow variations on the commands associated with a filetype, I would propose having a concept of a variant of a filetype. This is just extra information determined from a subset of the filetypes extensions. It can be implemented fully configurable from the filetypes.xxx file so no hard coded magic. An extract of the extended filetypes.c below shows what I mean:
[...]
Attached is a patch against the build-system branch revision 3195 which was before header filetypes changes. It gives you an idea of the amount of code needed to set the variant commands, not too much really and fairly localised. Obviously saving/restoring and using them is part of the upcoming build system changes so the patch does nothing visible.
Sorry guys,
but it seems we are getting a little off the road. The build-system branch has started to improve the build system a little, making it more flexible while keeping it almost as simple and easy to use as it by now. But all this is far away from this. I remember the beginning of this whole discussion where I stated my concerns about possible complexity introduced by Lex' suggestions. He then answered things will stay easy to use but only more flexible. The above don't seem so, sorry.
I don't want to block new things but I really want to keep the build system easy to use. I'd be happy to have some super-flexible and super-fancy build command things in a plugin which can build every file with every option in every possible way at any time or whatever.
But back to topic:
if we remove is_c_header() in build.c, header files can be compiled in the same way as any other C/C++ file. So I still don't see why you want anything more. At least, any other change is IMO not related to header files directly anymore. C header files are simple C source files, same syntax, same language. Only with different semantics but this doesn't affect the compiler or its options. I can compile header files with the same options as source files (to some extend, I'm really talking about compiling, not linking). Analogous the same is true for C++ headers and source files. But we all said this already.
And as far as I understood, your main intention on compiling header files is to easily check for compile errors. That way, the current Compile command should be enough (of course, with is_c_header() code being removed).
Regards, Enrico
2008/11/14 Enrico Tröger enrico.troeger@uvena.de
On Thu, 13 Nov 2008 19:39:43 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hi Guys,
Further thoughts on how to allow variations on the commands associated with a filetype, I would propose having a concept of a variant of a filetype. This is just extra information determined from a subset of the filetypes extensions. It can be implemented fully configurable from the filetypes.xxx file so no hard coded magic. An extract of the extended filetypes.c below shows what I mean:
[...]
Attached is a patch against the build-system branch revision 3195 which was before header filetypes changes. It gives you an idea of the amount of code needed to set the variant commands, not too much really and fairly localised. Obviously saving/restoring and using them is part of the upcoming build system changes so the patch does nothing visible.
Sorry guys,
but it seems we are getting a little off the road. The build-system branch has started to improve the build system a little, making it more flexible while keeping it almost as simple and easy to use as it by now. But all this is far away from this. I remember the beginning of this whole discussion where I stated my concerns about possible complexity introduced by Lex' suggestions. He then answered things will stay easy to use but only more flexible. The above don't seem so, sorry.
I don't want to block new things but I really want to keep the build system easy to use. I'd be happy to have some super-flexible and super-fancy build command things in a plugin which can build every file with every option in every possible way at any time or whatever.
But back to topic:
if we remove is_c_header() in build.c, header files can be compiled in the same way as any other C/C++ file. So I still don't see why you want anything more. At least, any other change is IMO not related to header files directly anymore. C header files are simple C source files, same syntax, same language. Only with different semantics but this doesn't affect the compiler or its options. I can compile header files with the same options as source files (to some extend, I'm really talking about compiling, not linking). Analogous the same is true for C++ headers and source files. But we all said this already.
And as far as I understood, your main intention on compiling header files is to easily check for compile errors. That way, the current Compile command should be enough (of course, with is_c_header() code being removed).
Regards, Enrico
HI,
It is relevant because we are talking about build commands. They just happen to be for headers
Enrico I don't like doing a job poorly, incompletely in incorrectly. I feel you are saying to me, spend the time providing an improved build system but in the end there will be one part of it that doesn't work and you are not allowed to fix it :-(. And it happens to be a part of the most common two languages!!
As I understand it the options you are offering are: 1. leave is_c_header() in and magically header files have no commands available. As I have explained at length before this is a poor solution for some users. 2. take is_c_header() out and all the C/C++ language commands are available. Compiling depends on the accident that the command for compiling headers is the same as for source. It is for gcc but not for other compilers. Also 'build' is available and will overwrite the file.o from file.cpp with the pre-compiled header from file.hpp. Wrong and confusing
and there is a half-way house
3. use is_c_header() to allow compile and prevent build and execute, again it magically works different to all other filetypes and still depends on the command being the same
All of these options are poor, incomplete or wrong.
Nick didn't want special case code in the program, but we could find a magic way of choosing between two sets of commands for C and C++ so it will at least work correctly from the end user point of view. It still requires much of the code and configuration that my last proposal had.
Instead of any special case code, my last proposal provided a general purpose solution that was configured from the data files. It required: 1. one extra function, 2. splitting one existing function into two which the build system change needs to do anyway, and 3. adding members to filetype private structure and document private structure
for a total of just over 60 lines. Its impact is cleanly localised and only adds to existing structures without changing the meaning of the existing members so it doesn't impact any other code. There is no user involvement with the content of the configuration files so it is no harder to use. This will be only a small part of the amount of changes build-system will need and would be part of that change.
I still think that my first solution of separate filetypes is the correct conceptual solution but I can understand your perceived problems with such a change so I won't propose it further.
As part of the build system changes the distinction between headers and source needs to be addressed, which is what we are doing discussing it. Designing the generalisation of the build system simply brought the issue to light.
Lex
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey,
reading your answer tells me I was too rude in my last mail, this was not intended.
As I understand it the options you are offering are:
- leave is_c_header() in and magically header files have no commands
available. As I have explained at length before this is a poor solution for some users.
I never wanted to actually suggest that. If I did so, sorry. The reason why is_c_header() exists is because I/we thought nobody will ever compile a header file. Since this assumption seems to be wrong, we should remove this function.
- take is_c_header() out and all the C/C++ language commands are
available. Compiling depends on the accident that the command for compiling headers is the same as for source. It is for gcc but not for other compilers. Also 'build' is available and will overwrite the file.o from file.cpp with the pre-compiled header from file.hpp. Wrong and confusing
Ok, I didn't know that you actually need special compiler commands. But one of your goals was to allow setting multiple (up to three, IIRC) filetype related build commands. So, an user can set one of those commands to compile header files. And voila, we are done. But I guess you will tell me that I'm wrong again and I forgot about anything.
- use is_c_header() to allow compile and prevent build and execute,
again it magically works different to all other filetypes and still depends on the command being the same
Nah, this wouldn't be nice.
As part of the build system changes the distinction between headers and source needs to be addressed, which is what we are doing discussing it.
Yes, that's right and I think 2. is the way to go. If I'm wrong again, do whatever you like and I won't complain anymore :). But please keep in mind to keep the whole stuff simple. Nobody wants to read 5 paragraphs in the manual just to compile a file.
Regards, Enrico
2008/11/17 Enrico Tröger enrico.troeger@uvena.de
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey,
reading your answer tells me I was too rude in my last mail, this was not intended.
No offense taken and I hope none caused by my reply.
As I understand it the options you are offering are:
- leave is_c_header() in and magically header files have no commands
available. As I have explained at length before this is a poor solution for some users.
I never wanted to actually suggest that. If I did so, sorry. The reason why is_c_header() exists is because I/we thought nobody will ever compile a header file. Since this assumption seems to be wrong, we should remove this function.
My misunderstanding, I thought you wanted to keep it, no problem.
- take is_c_header() out and all the C/C++ language commands are
available. Compiling depends on the accident that the command for compiling headers is the same as for source. It is for gcc but not for other compilers. Also 'build' is available and will overwrite the file.o from file.cpp with the pre-compiled header from file.hpp. Wrong and confusing
Ok, I didn't know that you actually need special compiler commands. But one of your goals was to allow setting multiple (up to three, IIRC) filetype related build commands. So, an user can set one of those commands to compile header files. And voila, we are done. But I guess you will tell me that I'm wrong again and I forgot about anything.
Well its possible, but if there is no distinction between headers and sources then the user has lost one of the commands for their sources because they have configured it into a header command. Whilst we could easily add an extra command, making it simple to implement, and it will work, I still worry that it isn't a very good one from the users point of view because even if we add an extra command there is still the problem of other source commands doing the wrong thing if invoked for headers. eg the standard source build command 'g++ -Wall -o "%e" "%f"' if invoked on a header, will overwrite the executable with a pre-compiled header file with the executable filename. Luckily on Linux it is not considered executable so it isn't dangerous, but it is confusing.
- use is_c_header() to allow compile and prevent build and execute,
again it magically works different to all other filetypes and still depends on the command being the same
Nah, this wouldn't be nice.
As part of the build system changes the distinction between headers and source needs to be addressed, which is what we are doing discussing it.
Yes, that's right and I think 2. is the way to go. If I'm wrong again, do whatever you like and I won't complain anymore :).
NEVER feel that you can't raise issues or suggestions, I just want to get the best result.
But please keep in mind to keep the whole stuff simple. Nobody wants to
read 5 paragraphs in the manual just to compile a file.
This is a good point,my intention is that from a user point of view there will be little changed, so I will look at re-arranging my changes to the build-system part of the manual as follows:
1. first a short description of how to use the build system with supplied defaults without too much reference to details. This will cover maybe 70% of the users. (Linux gcc, windows Mingw users I think) 2. then a more detailed description of the system including project building and configuring the commands via the GUI. Should cover most of the rest of the users 3. if there is anything not configurable by GUI then it can go in an appendix for the hard core tinkerers
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 17 Nov 2008 19:07:36 +1100, "Lex Trotman" elextr@gmail.com wrote:
2008/11/17 Enrico Tröger enrico.troeger@uvena.de
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey,
reading your answer tells me I was too rude in my last mail, this was not intended.
No offense taken and I hope none caused by my reply.
As I understand it the options you are offering are:
- leave is_c_header() in and magically header files have no
commands available. As I have explained at length before this is a poor solution for some users.
I never wanted to actually suggest that. If I did so, sorry. The reason why is_c_header() exists is because I/we thought nobody will ever compile a header file. Since this assumption seems to be wrong, we should remove this function.
My misunderstanding, I thought you wanted to keep it, no problem.
- take is_c_header() out and all the C/C++ language commands are
available. Compiling depends on the accident that the command for compiling headers is the same as for source. It is for gcc but not for other compilers. Also 'build' is available and will overwrite the file.o from file.cpp with the pre-compiled header from file.hpp. Wrong and confusing
Ok, I didn't know that you actually need special compiler commands. But one of your goals was to allow setting multiple (up to three, IIRC) filetype related build commands. So, an user can set one of those commands to compile header files. And voila, we are done. But I guess you will tell me that I'm wrong again and I forgot about anything.
Well its possible, but if there is no distinction between headers and sources then the user has lost one of the commands for their sources because they have configured it into a header command. Whilst we could
I don't think this(using one build command for headers) would be such a big problem but I also don't compile headers usually. I still don't like the source/header separation. See Nick's and my response later on in this thread.
easily add an extra command, making it simple to implement, and it will work, I still worry that it isn't a very good one from the users point of view because even if we add an extra command there is still the problem of other source commands doing the wrong thing if invoked for headers. eg the standard source build command 'g++ -Wall -o "%e" "%f"' if invoked on a header, will overwrite the executable with a pre-compiled header file with the executable filename. Luckily on
Ouch. Sorry, I didn't think of PCH since I never used them before. If you compile an header normally, it would fail because there is no main () and if there is a main() implementation that it's really not a header. But this is not true anymore with PCH which also compile without a main(). We should not forget that the user is at some point also responsible for what he is doing and we can't/shouldn't prevent any possible mistake he could do.
But please keep in mind to keep the whole stuff simple. Nobody wants to
read 5 paragraphs in the manual just to compile a file.
This is a good point,my intention is that from a user point of view there will be little changed, so I will look at re-arranging my changes to the build-system part of the manual as follows:
- first a short description of how to use the build system with
supplied defaults without too much reference to details. This will cover maybe 70% of the users. (Linux gcc, windows Mingw users I think) 2. then a more detailed description of the system including project building and configuring the commands via the GUI. Should cover most of the rest of the users 3. if there is anything not configurable by GUI then it can go in an appendix for the hard core tinkerers
Sounds reasonable, I like the idea of splitting the whole description. 1. sounds like the famous 'for the impatient people' sections :).
Regards, Enrico
On Fri, 14 Nov 2008 12:00:54 +1100 "Lex Trotman" elextr@gmail.com wrote:
Nick didn't want special case code in the program, but we could find
Not sure I actually said that, maybe implied it. I was arguing against adding header filetypes.
a magic way of choosing between two sets of commands for C and C++ so it will at least work correctly from the end user point of view. It still requires much of the code and configuration that my last proposal had.
I haven't looked at this, but is this likely to be needed as a general feature?
In another email I just sent I suggest just having an extra command to compile headers for a filetype/project. I think this is simpler and still gets the job done.
Regards, Nick
Hi,
On Wed, 12 Nov 2008 14:23:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
- Use custom commands, but we still have the two commands problem
from the item above and this is something that Geany really should offer its users as standard, not requiring them to configure it.
- Use project/user preference commands. Now unwanted commands are
visible on all languages which is worse, and we have the same problem that it should be standard.
My thoughts are that for a compile header command, this can be an _extra_ build command, so not losing compile, build, etc. As I originally said, ideally we wouldn't limit how many commands the user can run, it's up to them.
So, _if_ compiling a header is a generic command for a filetype, have an extra build command configured for the C++ filetype (and C if you want).
But more likely, compiling a header requires the include arguments for library headers, etc, so it would make more sense as an extra project command.
But either of these can work with a simple build system. The only disadvantage I can see is that you would have to remember to use a different command from the usual compile/build/whatever you use for source files. But I think this is reasonable.
Regards, Nick
On Mon, 17 Nov 2008 17:14:26 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
On Wed, 12 Nov 2008 14:23:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
- Use custom commands, but we still have the two commands problem
from the item above and this is something that Geany really should offer its users as standard, not requiring them to configure it.
- Use project/user preference commands. Now unwanted commands are
visible on all languages which is worse, and we have the same problem that it should be standard.
My thoughts are that for a compile header command, this can be an _extra_ build command, so not losing compile, build, etc. As I originally said, ideally we wouldn't limit how many commands the user can run, it's up to them.
So, _if_ compiling a header is a generic command for a filetype, have an extra build command configured for the C++ filetype (and C if you want).
But more likely, compiling a header requires the include arguments for library headers, etc, so it would make more sense as an extra project command.
But either of these can work with a simple build system. The only disadvantage I can see is that you would have to remember to use a different command from the usual compile/build/whatever you use for source files. But I think this is reasonable.
I fully agree on this. This is basically what I suggested yesterday (except for that I thought of using a header compile command as one of filetype commands and not project commands).
Regards, Enrico
Hi Guys,
I'm now a little confused, I think we have a terminology problem so let me spell out what I mean below. We can continue to try to sort out the best solution by discussion because I have a sudden family problem and will be away from home and work and unable to code anything for a couple of weeks. I will be able to continue discussion thanks to gmail being accessible anywhere. Perhaps we should slow the discussion down to every couple of days so as to not use too much of your time.
I am confused about what we each mean when we are talking about 'build' here, and looking back I am not sure I have been consistent in my usage either. So I suggest the terminology for this discussion:
1. Filetype commands, menu items labelled: - compile, - build which I suggest we call build(link) to distinguish it from other meanings of build and - execute.
These commands depend on the filetype and and in the new build system will have user configurable menu label and commands stored in the user preferences directory (as is currently done for the commands only).
2. Preference commands, that is the menu items currently labelled 'make something', which I suggest we call make commands to distinguish them from the filetype build command. These commands will have configurable menu label and command stored in the user preference directory. These commands can also contain an override for the execute command.
3. Project commands which override preference commands (make commands) when a project is open. If changed whilst a project is open they will be stored in the project file. These commands can also contain an override for the execute command.
For most of this discussion on headers I have been talking about filetype commands because both preference and project make commands are independant of the type of file that is open. Having language specific commands in command sets that are present for all languages is not a nice solution. And if it is in project files then the user has to configure it again and again for each project.
Although having header compile as an extra filetype command can work, the build(link) menu item can do funny things if invoked on header files. This is probably fine for an expert like Nick but could be an issue for a beginner just trying things out, thats why I don't like having commands that are not useful available to users.
In the time that I'm away lets see if we can find a solution that doesn't have the problems I've listed above or in previous emails but is simple to implement. Thanks for your patience we will get there.
Cheers Lex
2008/11/18 Enrico Tröger enrico.troeger@uvena.de
On Mon, 17 Nov 2008 17:14:26 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi,
On Wed, 12 Nov 2008 14:23:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
- Use custom commands, but we still have the two commands problem
from the item above and this is something that Geany really should offer its users as standard, not requiring them to configure it.
- Use project/user preference commands. Now unwanted commands are
visible on all languages which is worse, and we have the same problem that it should be standard.
My thoughts are that for a compile header command, this can be an _extra_ build command, so not losing compile, build, etc. As I originally said, ideally we wouldn't limit how many commands the user can run, it's up to them.
I agree that the ultimate would be to have unlimited commands, but that makes for a more complex configuration GUI and configuration/preference/project file format. My proposal for now is to add one extra filetype command (compile, build(link), execute and spare) and one extra make command (make all, make custom, make object, execute and spare), remembering all labels and commands can be configured..
So, _if_ compiling a header is a generic command for a filetype, have an extra build command configured for the C++ filetype (and C if you want).
As I said above I am confused about where you are suggesting this command to be added, as a filetype command or as a make command?
But more likely, compiling a header requires the include arguments for library headers, etc, so it would make more sense as an extra project command.
I'm also confused by this, headers (in my experience) don't need any more include paths than the source file needs ( I guess you are talking about things like Gtk+ and the like that use pkg-config, most other stuff is in the search paths by default for my C++). So the compile command for headers would have the same includes and agruments as the command for sources.
Compiling headers as a project make command would be great, but I don't know how to set up make and other builders to compile headers (remember that the original reason for my build commands changes was to support different builders) If there is no output file, what prevents make compiling all the headers every time? Gcc leaves a .gch file but not all compilers do that (eg Intel C++ for Linux).
Anyway all I really want is to be able to compile my new or newly modified C++ header file for syntax check purposes. Once it doesn't inject several hundred syntax errors into the source files that include it I can get on with making them compile and making it actually work using the make commands. (Yes, the most recent new C++ header file I built had several hundred lines of error messages on first compile (not bad for a file only 370 lines long), This is common because some C++ syntax is really picky and unintuitive (meaning templates) and takes a few tries to get right and C++ headers typically have more in them than C headers.
But either of these can work with a simple build system. The only disadvantage I can see is that you would have to remember to use a different command from the usual compile/build/whatever you use for source files. But I think this is reasonable.
As I said above, for experts it is reasonable but as the filetype commands are probably more used by beginners who havn't got up to speed with make yet, I see having it available as a problem.
I fully agree on this. This is basically what I suggested yesterday (except for that I thought of using a header compile command as one of filetype commands and not project commands).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 18 Nov 2008 21:53:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
I am confused about what we each mean when we are talking about 'build' here, and looking back I am not sure I have been consistent in my usage either. So I suggest the terminology for this discussion:
- Filetype commands, menu items labelled:
- compile,
- build which I suggest we call build(link) to distinguish it from
other meanings of build and
- execute.
OK, I'll try to do this.
Although having header compile as an extra filetype command can work, the build(link) menu item can do funny things if invoked on header files. This is probably fine for an expert like Nick but could be an issue for a beginner just trying things out, thats why I don't like having commands that are not useful available to users.
OK, so this is another reason why compiling headers with an extra command is not ideal. The other reason is that it's less natural to use a different command.
I will try to look at your build command variants code sometime.
My thoughts are that for a compile header command, this can be an _extra_ build command, so not losing compile, build, etc. As I originally said, ideally we wouldn't limit how many commands the user can run, it's up to them.
I agree that the ultimate would be to have unlimited commands, but that makes for a more complex configuration GUI and configuration/preference/project file format. My proposal for now is to add one extra filetype command (compile, build(link), execute and spare) and one extra make command (make all, make custom, make object, execute and spare), remembering all labels and commands can be configured..
Yes, this is fine to implement a fixed number of commands now. In future we may extend this to be unlimited. But don't worry about this.
So, _if_ compiling a header is a generic command for a filetype, have an extra build command configured for the C++ filetype (and C if you want).
As I said above I am confused about where you are suggesting this command to be added, as a filetype command or as a make command?
Either a filetype or a project command, depending on how the user wants to compile headers. It sounds like you would want a filetype command to do this, so it was only available for C documents; I would want a project command probably because I use libraries that use pkg-config for include file paths.
We can't use a make command because we don't know what the precompiled header (PCH) extension is. Although that could be configurable like 'Make Object', maybe it wouldn't be so useful because people might not want to have to add PCH targets to all their makefiles.
Compiling headers as a project make command would be great, but I don't know how to set up make and other builders to compile headers (remember that the original reason for my build commands changes was to support different builders) If there is no output file, what prevents make compiling all the headers every time? Gcc leaves a .gch file but not all compilers do that (eg Intel C++ for Linux).
OK, out of interest, how do they record the compiled header output? In a single cache file? If there's a file somewhere, you can write makefile targets that depend on header file changes. But as I said, maybe people don't want to have to add PCH makefile targets anyway, even if it's possible.
Regards, Nick
2008/11/20 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 18 Nov 2008 21:53:47 +1100 "Lex Trotman" elextr@gmail.com wrote:
I am confused about what we each mean when we are talking about 'build' here, and looking back I am not sure I have been consistent in my usage either. So I suggest the terminology for this discussion:
- Filetype commands, menu items labelled:
- compile,
- build which I suggest we call build(link) to distinguish it from
other meanings of build and
- execute.
OK, I'll try to do this.
Although having header compile as an extra filetype command can work, the build(link) menu item can do funny things if invoked on header files. This is probably fine for an expert like Nick but could be an issue for a beginner just trying things out, thats why I don't like having commands that are not useful available to users.
OK, so this is another reason why compiling headers with an extra command is not ideal. The other reason is that it's less natural to use a different command.
I will try to look at your build command variants code sometime.
Ok, remember that there is still the quick and dirty option of testing for headers explicitly. I was trying to avoid it, but, if the test is in place of the call to the new get_variant function (or whatever I called it, I don't have the code with me) and the result is stored in the document as I did with the variant, then the test only has to exist in one place and can be clearly commented.
My thoughts are that for a compile header command, this can be an _extra_ build command, so not losing compile, build, etc. As I originally said, ideally we wouldn't limit how many commands the user can run, it's up to them.
I agree that the ultimate would be to have unlimited commands, but that makes for a more complex configuration GUI and configuration/preference/project file format. My proposal for now is to add one extra filetype command (compile, build(link), execute and spare) and one extra make command (make all, make custom, make object, execute and spare), remembering all labels and commands can be configured..
Yes, this is fine to implement a fixed number of commands now. In future we may extend this to be unlimited. But don't worry about this.
So, _if_ compiling a header is a generic command for a filetype, have an extra build command configured for the C++ filetype (and C if you want).
As I said above I am confused about where you are suggesting this command to be added, as a filetype command or as a make command?
Either a filetype or a project command, depending on how the user wants to compile headers. It sounds like you would want a filetype command to do this, so it was only available for C documents;
That is where I'd like to put the default header compile command, there is no reason not to have the ability on make commands as well if the makefile supports it.
I would want a project command probably because I use libraries that use pkg-config for include file paths.
Yes of course, I try if at all possible not to pull such things into header files which means that I don't need any extra includes and then it is not imported into all files that use the header. I try to keep these things in implementation specific parts, but of course it is not always possible.
We can't use a make command because we don't know what the precompiled header (PCH) extension is. Although that could be configurable like 'Make Object', maybe it wouldn't be so useful because people might not want to have to add PCH targets to all their makefiles.
And it isn't portable see below.
Compiling headers as a project make command would be great, but I don't know how to set up make and other builders to compile headers (remember that the original reason for my build commands changes was to support different builders) If there is no output file, what prevents make compiling all the headers every time? Gcc leaves a .gch file but not all compilers do that (eg Intel C++ for Linux).
OK, out of interest, how do they record the compiled header output? In a single cache file? If there's a file somewhere, you can write makefile targets that depend on header file changes. But as I said, maybe people don't want to have to add PCH makefile targets anyway, even if it's possible.
A quick straw poll among users of other compilers gave:
1. Some compilers ignore header files listed on the command line. 2. Compilers that don't do pre-compiled headers output nothing, a degenerate .o or .obj file (or as set by -o option) for compiling a header file. 3. Compilers that do pre-compiled headers seem to have compiler specific extensions. Probably good since they are unlikely to have the same internal format. Nobody we know uses a single cache for C/C++ compilation results, but it may happen in future. Ada operates that way, although many compilers still use separate files but in one directory. Of course thats assuming that you arn't using ccache or similar ;-)
All very non-portable I'm afraid
On unix we could always dump unwanted output files into /dev/null using -o and touch a dummy file to indicate that re-compilation isn't needed, but again not portable outside unix. I don't know if autoconf, cmake or any of the other configurators could help.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 11 Nov 2008 14:26:39 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey,
The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important. So is compiling .h files independently, it is annoying having to pick through errors in the .cpp file (often caused by errors in the .h file) to find the .h errors and fix them first, usually it gets so
As Nick already said, this is a build command issue. With the current code, one solution could be to remove the limitation that headers files can't be compiled. I don't remember exactly why I added this but mainly because until this thread I was thinking compiling header files doesn't make any sense at all. Maybe there were other reasons, too. Anyway, there should be really no need for separate header filetypes. And since you are currently about to rework the build system, just make the custom filetype build commands work with header files.
The marking -*-C++-*- exists on all GNU headers which means it should be present on most Linuxii, I don't know about windows though. Looking at other (non-system) library headers I've got available, most of the C++ .h files identify themselves and interestingly about 15% of the C .h files identify themselves as C. In terms of the delays in opening the file, it is only intended to look at line 1 which has already been examined for shebang so it is already available in memory, most of the overhead has already occurred. Having separate C+
Yup, this is why I said the check should work on the first line or the first both lines. Then it doesn't cause much more overhead than already existent.
- header templates with the mark already in it would help users to
remember to add it. BTW it would be good to have these separate .h .hpp templates irrespective of the end result of these discussions because creating headers using C or C++ templates and filenames means you need to delete the main you don't want, add the guards etc.and then change the file extension on save too.
Check the classbuilder plugin. It's not exactly the same but it creates C++ class files and the corresponding headers, including guards and all this stuff. Unfortunately, the used templates in the plugin are not (yet) configurable but this is an easy task, it just needs to be done. Alternatively, Nick already stated about custom file templates.
Regards, Enrico
On Fri, 7 Nov 2008 17:02:48 +1100 "Lex Trotman" elextr@gmail.com wrote:
No problem, it is more important that a project chooses and sticks to a
style than what the style actually is. On the other hand formatting is the sort of rote activity that I believe computers should do, not people. On that basis my work experience student now knows much more than she ever wanted to about C code formatters. We have found one, 'uncrustify' that seems to do what we want without doing too much extra, I have committed a version of build.c run through it for you to have a look at. uncrustify is very flexible (about 250-300 options) and it seems to be able to enforce all the requirements of HACKING. The only extra things that I can't stop it doing are:
- positioning the alignment of variable definitions and parameters
slightly different to the originals (still aligns and hangs * though)
- aligning function call continuations with the open parens, I think
it is ok, see what you think. It can cause the call to need more wrapping though.
The wrapping of long lines is a little simplistic for long function calls that are already manually wrapped, needs a bit of a helping hand but not very often.
Thanks, but I don't like the existing code being reformatted with different alignment really. What are the options you used?
...
NOTE: this brings up one significant change needed for the full version, the can compile, can build, flags of the filetype will no longer be used since the existance (or not) of such a command is what determines if a menu item is shown. Otherwise users would not be
I agree, I wanted to remove them before.
able to add filetype commands to unused filetype menu items. So in the full version, a commandwhich is not set will mean use the default whilst one set to nothing (item name) will mean don't use. Have to allow 'command set to nothing' just in case someone wants to use the make custom dialog to type the whole command, possibly useful for occasionally used commands whilst still capturing and parsing the command output.
But are there any other important uses of these flags besides controlling what is shown in the build menu?
If so, they can be replaced with if (NZV(ft_command_str)) checks (or maybe just checks against null for the custom command).
Ok, i'll take that as removal is ok
Yes.
Regards, Nick
On Mon, 10 Nov 2008 13:00:09 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 7 Nov 2008 17:02:48 +1100 "Lex Trotman" elextr@gmail.com wrote:
No problem, it is more important that a project chooses and sticks to a
style than what the style actually is. On the other hand formatting is the sort of rote activity that I believe computers should do, not people. On that basis my work experience student now knows much more than she ever wanted to about C code formatters. We have found one, 'uncrustify' that seems to do what we want without doing too much extra, I have committed a version of build.c run through it for you to have a look at. uncrustify is very flexible (about 250-300 options) and it seems to be able to enforce all the requirements of HACKING. The only extra things that I can't stop it doing are:
- positioning the alignment of variable definitions and parameters
slightly different to the originals (still aligns and hangs * though)
- aligning function call continuations with the open parens, I think
it is ok, see what you think. It can cause the call to need more wrapping though.
The wrapping of long lines is a little simplistic for long function calls that are already manually wrapped, needs a bit of a helping hand but not very often.
Thanks, but I don't like the existing code being reformatted with different alignment really. What are the options you used?
Additionally, I can't really understand your(Lex) troubles with the indentation at all. It's pretty simple: we use tabs with a tab width of 4 characters. This is IMO the most simplest form of indentation at all. I never had the need of using an external code formatter for this type (for writing new code).
Regards, Enrico
2008/11/11 Enrico Tröger enrico.troeger@uvena.de
On Mon, 10 Nov 2008 13:00:09 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 7 Nov 2008 17:02:48 +1100 "Lex Trotman" elextr@gmail.com wrote:
Thanks, but I don't like the existing code being reformatted with different alignment really. What are the options you used?
Attached the config file, the only setting that seems to touch things you don't want is indent_func_call_param which is true/false selecting indent one level or indent to open parens. Quite frankly I found the indent one level awful so I picked open parens. There seems no way of turning it off which is what we want.
Additionally, I can't really understand your(Lex) troubles with the indentation at all. It's pretty simple: we use tabs with a tab width of 4 characters. This is IMO the most simplest form of indentation at all. I never had the need of using an external code formatter for this type (for writing new code).
The indentation problem only existed because the first version committed had mixed indentation, I am not sure but maybe it was a 0.14 problem with the setting, since I installed 0.15 everything is coming up tabs. Hopefully this is fixed.
My real reason for suggesting a formatter was not for indentation but for other areas of the code eg spaces around ()s other operators etc. I was simply trying to ensure that my code matched your expectations taking into account that the format is different to what I use most of the time, and being human I am going to get it wrong sometimes, no matter how often I re-read it. Using a formatter was a way of fixing that, but unfortunately they all seemed to have side effects. The one I suggested simply had the least.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 11 Nov 2008 14:16:19 +1100 "Lex Trotman" elextr@gmail.com wrote:
Thanks, but I don't like the existing code being reformatted with different alignment really. What are the options you used?
Attached the config file, the only setting that seems to touch things you don't want is indent_func_call_param which is true/false selecting indent one level or indent to open parens. Quite frankly I found the indent one level awful so I picked open parens. There seems no way of turning it off which is what we want.
Thanks for the file, it might be useful when receiving patches. But all the same, the existing code shouldn't be reformatted. Maybe it could be restored manually with Meld?
Regards, Nick
