Hi
I have been looking at the implementation of the build-system and in particular interactions with other parts of Geany. In general it looks ok, but the latex menus and commands system seems to have a few interactions with the build system and menu.
Since the new build-system allows the menu labels to be changed, (not just the commands) if I allow two run commands can we bring the latex build system back into the normal system?
This has the advantages: 1. removal of lots of nearly duplicate code building menus, dialogs and commands 2. much simpler and cleaner build system (I'm not all that altruistic, this means that it is easy for me to see what I might break with my changes ;-)
Can anyone point me at any glaringly obvious problems that I've overlooked?
Cheers Lex
On Mon, 11 May 2009 18:44:15 +1000, Lex wrote:
Hi
I have been looking at the implementation of the build-system and in particular interactions with other parts of Geany. In general it looks ok, but the latex menus and commands system seems to have a few interactions with the build system and menu.
Since the new build-system allows the menu labels to be changed, (not just the commands) if I allow two run commands can we bring the latex build system back into the normal system?
I'd say we don't even need two run commands. Either interested users 'abuse' one of the build commands or they realise that most often one run command is enough (based on my personal workflow with LaTeX, you usually use only viewing DVIs or PDFs). And e.g. when using evince, you don't even need a Run command at all as it reloads the opened file once it has been regenerated.
This has the advantages:
- removal of lots of nearly duplicate code building menus, dialogs and
commands 2. much simpler and cleaner build system (I'm not all that altruistic, this means that it is easy for me to see what I might break with my changes ;-)
Please, please do that. Remove all LaTeX-specific code now. For me, this is one of the biggest advantages of your new code :).
The reason for the special LaTeX code was only to provide special stuff for LaTeX. But with your new build system, this all should be easier and cleaner. Please remove it.
Regards, Enrico
2009/5/12 Enrico Tröger enrico.troeger@uvena.de
On Mon, 11 May 2009 18:44:15 +1000, Lex wrote:
Hi
I have been looking at the implementation of the build-system and in particular interactions with other parts of Geany. In general it looks ok, but the latex menus and commands system seems to have a few interactions with the build system and menu.
Since the new build-system allows the menu labels to be changed, (not just the commands) if I allow two run commands can we bring the latex build system back into the normal system?
I'd say we don't even need two run commands. Either interested users 'abuse' one of the build commands or they realise that most often one run command is enough (based on my personal workflow with LaTeX, you usually use only viewing DVIs or PDFs). And e.g. when using evince, you don't even need a Run command at all as it reloads the opened file once it has been regenerated.
The command would actually have to be the extra filetype dependent command since its existence depends on the current file being latex. Of course it could be a non-filetype dependent command if the user didn't care if it was always available, but thats up to them, I think we should default it to the filetype command since as a C++ (mostly) programmer I wouldn't want a latex command in my makes ;-).
This has the advantages:
- removal of lots of nearly duplicate code building menus, dialogs and
commands 2. much simpler and cleaner build system (I'm not all that altruistic, this means that it is easy for me to see what I might break with my changes ;-)
Please, please do that. Remove all LaTeX-specific code now. For me, this is one of the biggest advantages of your new code :).
The reason for the special LaTeX code was only to provide special stuff for LaTeX. But with your new build system, this all should be easier and cleaner. Please remove it.
Will do.
I have also noticed that the plugins interface exposes build_info which has the build type enum in it. This enum will of course change due to the addition of extra commands, I can add new things to the end so that the ABI is preserved, but plugins may need to be changed to consider the extra commands. And adding them at the end will mean the filetype and non-filetype command groups are no longer contiguous. This isn't a problem for me but may be elsewhere, do you know of anything that is dependent on the order of the enum or is adding to the end ok?.
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, 12 May 2009 17:04:06 +1000, Lex wrote:
2009/5/12 Enrico Tröger enrico.troeger@uvena.de
On Mon, 11 May 2009 18:44:15 +1000, Lex wrote:
Hi
I have been looking at the implementation of the build-system and in particular interactions with other parts of Geany. In general it looks ok, but the latex menus and commands system seems to have a few interactions with the build system and menu.
Since the new build-system allows the menu labels to be changed, (not just the commands) if I allow two run commands can we bring the latex build system back into the normal system?
I'd say we don't even need two run commands. Either interested users 'abuse' one of the build commands or they realise that most often one run command is enough (based on my personal workflow with LaTeX, you usually use only viewing DVIs or PDFs). And e.g. when using evince, you don't even need a Run command at all as it reloads the opened file once it has been regenerated.
The command would actually have to be the extra filetype dependent command since its existence depends on the current file being latex. Of course it could be a non-filetype dependent command if the user didn't care if it was always available, but thats up to them, I think we should default it to the filetype command since as a C++ (mostly) programmer I wouldn't want a latex command in my makes ;-).
You mean the extra Run command for LaTex? I think we can just drop it (for now). Users who need it, can then just add it if necessary.
This has the advantages:
- removal of lots of nearly duplicate code building menus, dialogs
and commands 2. much simpler and cleaner build system (I'm not all that altruistic, this means that it is easy for me to see what I might break with my changes ;-)
Please, please do that. Remove all LaTeX-specific code now. For me, this is one of the biggest advantages of your new code :).
The reason for the special LaTeX code was only to provide special stuff for LaTeX. But with your new build system, this all should be easier and cleaner. Please remove it.
Will do.
I have also noticed that the plugins interface exposes build_info which has the build type enum in it. This enum will of course change due to the addition of extra commands, I can add new things to the end so that the ABI is preserved, but plugins may need to be changed to consider the extra commands. And adding them at the end will mean the filetype and non-filetype command groups are no longer contiguous. This isn't a problem for me but may be elsewhere, do you know of anything that is dependent on the order of the enum or is adding to the end ok?.
I just grepped over my local geany-plugins checkout and it didn't find any references. According to the commit message, the build_info code was exported to the plugin API by a request by "blackdog" but no idea why he needed it and whether he still needs it. But if you don't even need to remove/change fields of the struct but only append to it, there shouldn't be a problem I guess. Just remember to increase the API version.
Regards, Enrico
Hi,
I have found a couple of places where there is hard coded behavior for specific build menu commands which needs to be addressed when commands are generalised.
The first place is the "make in base directory" option is hard coded to only be applied to make custom and make all but not make object.
I suggest that:
1. all filetype dependent commands are executed in the file's directory (current behavior) 2. when no project is open, all non-file type dependent commands are run in the directory of the current file (current behavior) 3. when a project is open, each non-file type dependent command has its own selection to make in base path or directory of the current file. That way a user can set the behavior to suit the command. Note that this option does not require the command to be defined in the project as the option can just as usefully be added to the default make commands as to user set specific commands. The option works in the same way as the labels and commands will, ie a project value overrides preference value overrides default value.
The second piece of hard coded behavior is in the removal of error markers from files. Currently the "compile file" and "make object" commands clear errors only for the current file, but all other commands including "build file" clear the errors from all the open files. I don't understand why the first two commands only affect the current file as, although they compile/build just that file, they can still cause errors in other files through includes etc. Also the markers that are left in other files no longer have corresponding error messages in the compile window since these are cleared when the command is run, causing potential confusion as to why the error marker is there. Unless I have missed an important use-case I propose that all build menu commands clear all error markers each time, then there is no confusion about what caused the mark.
Progressing slowly but steadily.
Cheers Lex
On Tue, 19 May 2009 20:41:11 +1000, Lex wrote:
Hey,
sorry for the delay :(.
The first place is the "make in base directory" option is hard coded to only be applied to make custom and make all but not make object.
I suggest that:
- all filetype dependent commands are executed in the file's directory
(current behavior) 2. when no project is open, all non-file type dependent commands are run in the directory of the current file (current behavior) 3. when a project is open, each non-file type dependent command has its own selection to make in base path or directory of the current file. That way a user can set the behavior to suit the command. Note that this option does not require the command to be defined in the project as the option can just as usefully be added to the default make commands as to user set specific commands. The option works in the same way as the labels and commands will, ie a project value overrides preference value overrides default value.
Yes to 1 and 2, as it is the current behaviour :). I don't have such a strong opinion on 3). My concern would only be that things get more complicated by adding a 'execute in base path' option but OTOH why should we limit the new features again unnecessarily. So, if you like to, go for it.
The second piece of hard coded behavior is in the removal of error markers from files. Currently the "compile file" and "make object" commands clear errors only for the current file, but all other commands including "build file" clear the errors from all the open files. I don't understand why the first two commands only affect the current file as, although they compile/build just that file, they can still cause errors in other files through includes etc. Also the markers that are left in other files no longer have corresponding error messages in the compile window since these are cleared when the command is run, causing potential confusion as to why the error marker is there. Unless I have missed an important use-case I propose that all build menu commands clear all error markers each time, then there is no confusion about what caused the mark.
Yeah, the idea for not clearing the error markers of other files was, as you mentioned, that Compile/Build and Make Object only affects the current file. But you are also right, that previous error markers in other files gets more or less invalid after a new build command is executed, so I'd agree to clear them all unconditionally for every build command.
Regards, Enrico