Hello,
Just reinstalled geany. I managed to setup a filetype for Go files. All works fine, files of the types are recognised as such and editor features work as excepted; except for the build settings. They do not seem to be taken into account at all, and geany's interface desactivates corresponding buttons compile and build (run is active while looking as inactive, and indeed is useles if source aren't build ;-) Here are my settings from custom filetypes.Go.conf:
[build_settings] # %f will be replaced by the complete filename # %e will be replaced by the filename without extension # (use only one of it at one time) # Compiler: 8g -- Linker: 8l # Compile flag 'e' --> no limit on number of errors compiler=8g -e "%f" linker=8l -o "%e" "%e".8 run_cmd=./"%e"
In the same way, build settings manually input from the interface via menu Build/Set build commands are not taken into account (this used to work in previous versions, but there were explicit compile and build lines if i remenber right).
Denis
On 06/02/2012 10:21, spir wrote:
Hello,
Just reinstalled geany. I managed to setup a filetype for Go files. All works fine, files of the types are recognised as such and editor features work as excepted; except for the build settings. They do not seem to be taken into account at all, and geany's interface desactivates corresponding buttons compile and build (run is active while looking as inactive, and indeed is useles if source aren't build ;-) Here are my settings from custom filetypes.Go.conf:
[build_settings] # %f will be replaced by the complete filename # %e will be replaced by the filename without extension # (use only one of it at one time) # Compiler: 8g -- Linker: 8l # Compile flag 'e' --> no limit on number of errors compiler=8g -e "%f" linker=8l -o "%e" "%e".8 run_cmd=./"%e"
That's the old style way to define them. Try using the [build-menu] style. For an example see Geany's filetypes.Genie.conf file.
In the same way, build settings manually input from the interface via menu Build/Set build commands are not taken into account (this used to work in previous versions, but there were explicit compile and build lines if i remenber right).
Maybe that will work if the new conf style is used?
Nick
On 02/06/2012 05:23 PM, Nick Treleaven wrote:
On 06/02/2012 10:21, spir wrote:
Hello,
Just reinstalled geany. I managed to setup a filetype for Go files. All works fine, files of the types are recognised as such and editor features work as excepted; except for the build settings. They do not seem to be taken into account at all, and geany's interface desactivates corresponding buttons compile and build (run is active while looking as inactive, and indeed is useles if source aren't build ;-) Here are my settings from custom filetypes.Go.conf:
[build_settings] # %f will be replaced by the complete filename # %e will be replaced by the filename without extension # (use only one of it at one time) # Compiler: 8g -- Linker: 8l # Compile flag 'e' --> no limit on number of errors compiler=8g -e "%f" linker=8l -o "%e" "%e".8 run_cmd=./"%e"
That's the old style way to define them. Try using the [build-menu] style. For an example see Geany's filetypes.Genie.conf file.
In the same way, build settings manually input from the interface via menu Build/Set build commands are not taken into account (this used to work in previous versions, but there were explicit compile and build lines if i remenber right).
Maybe that will work if the new conf style is used?
Nick
Thank you. In filedefs.Go.conf, I set (copying from filetypes.Genie.conf):
[build-menu] FT_00_LB=_Compile FT_00_CM=8g -e "%f" FT_00_WD= FT_01_LB=_Build FT_01_CM=8l -o "%e" "%e".8 FT_01_WD=
It worked for compiling and linking, not run (via F5, icon, or in Build menu) (and the icon is still greyed). Thus, I added:
FT_01_LB=_Execute FT_01_CM=./"%e" FT_01_WD=
Normal execute still does not work (and the icon is still greyed). But a *second* "Execute" entry appeared in the Build menu, which works as expected. But as you can guess it is not practicle (and I think I cannot attach a shortcut, even less an icon, to this new entry?). What else? I don't truely understand the principle, even less the reasoning, behind this "new way" build settings. The doc did not help. Is there a place where I can find rationales and explanations?
Denis
PS: Some parts of the doc would benefit of exemples, esp. how to define a new language. I would help a bit if it were a wiki ;-).
On 7 February 2012 05:52, spir denis.spir@gmail.com wrote:
On 02/06/2012 05:23 PM, Nick Treleaven wrote:
On 06/02/2012 10:21, spir wrote:
Hello,
Just reinstalled geany. I managed to setup a filetype for Go files. All works fine, files of the types are recognised as such and editor features work as excepted; except for the build settings. They do not seem to be taken into account at all, and geany's interface desactivates corresponding buttons compile and build (run is active while looking as inactive, and indeed is useles if source aren't build ;-) Here are my settings from custom filetypes.Go.conf:
[build_settings] # %f will be replaced by the complete filename # %e will be replaced by the filename without extension # (use only one of it at one time) # Compiler: 8g -- Linker: 8l # Compile flag 'e' --> no limit on number of errors compiler=8g -e "%f" linker=8l -o "%e" "%e".8 run_cmd=./"%e"
That's the old style way to define them. Try using the [build-menu] style. For an example see Geany's filetypes.Genie.conf file.
In the same way, build settings manually input from the interface via menu Build/Set build commands are not taken into account (this used to work in previous versions, but there were explicit compile and build lines if i remenber right).
Maybe that will work if the new conf style is used?
Nick
Thank you. In filedefs.Go.conf, I set (copying from filetypes.Genie.conf):
[build-menu] FT_00_LB=_Compile FT_00_CM=8g -e "%f" FT_00_WD= FT_01_LB=_Build FT_01_CM=8l -o "%e" "%e".8 FT_01_WD=
It worked for compiling and linking, not run (via F5, icon, or in Build menu) (and the icon is still greyed). Thus, I added:
FT_01_LB=_Execute FT_01_CM=./"%e" FT_01_WD=
Use EX_00_LB etc.
Normal execute still does not work (and the icon is still greyed). But a *second* "Execute" entry appeared in the Build menu, which works as expected. But as you can guess it is not practicle (and I think I cannot attach a shortcut, even less an icon, to this new entry?). What else? I don't truely understand the principle, even less the reasoning, behind this "new way" build settings. The doc did not help. Is there a place where I can find rationales and explanations?
The best way would be to use the "set build commands" dialog to edit simple commands rather than doing it manually.
Cheers Lex
Denis
PS: Some parts of the doc would benefit of exemples, esp. how to define a new language. I would help a bit if it were a wiki ;-).
PS Note there is a wiki entry on configuring the build system at http://wiki.geany.org/howtos/configurebuildmenu
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 02/06/2012 09:11 PM, Lex Trotman wrote:
PS Note there is a wiki entry on configuring the build system at http://wiki.geany.org/howtos/configurebuildmenu
First, thank you and bravo for this wiki page on the topic. It is great and above all clear. Reading it not only helped but also launched a few comments to possibly still ameliorate the system on details, and a 2 questions on remaining obscure points. If ever I finally understand things well enough, I'll help and improve the wiki page. Also add one on settings for Go, and possibly a general one on how to introduce a new language (this badly lacks in geany doc).
*** Questions ***
* toolbar buttons? The relation between the build menu config (either in files or via GUI) and toolbar is unclear for me. I guess --because it seems to work that way on my machine-- that ~ If ever, resulting from config, there are "Compile" & "Build" entries in the 1st section of the menu, then they map to matching buttons. ~ The Execute button's command is always set by the Execute line of the menu, meaning in config the first line of the fourth section. If true, then I find that difficult to get. I tried both in files and through GUI to set an Execute command, like the Compile & Build ones, which doubled the predefined one without any effect. Conversely, why is there no predefined entries for the Compile & Build like for Execute? Sure, they do not apply to interpreted languages, but the entries could still be there, no?
* Relation between config files & GUI settings? What happens to the config after changing settings on the GUI. They double the files' role. What kind of relation are there between GUI setting and config files, in both relations? Who wins? The page pointed above lists the "cascade" of config locations in files, but does not include the GUI settings. Conversely, what happens to the GUI settings after changing files? I think we may do without these GUI that double and complicate the config system. Simply, the config files would as standard propose parameter lines equivalent to the present GUI, and the doc would state that it is recommended to stop there. ("With power comes responsability")
*** Comments ***
* Build Menu orga It may be reorganised so that the 3 configurable sections (out of 5) come 1st, 2nd, 3rd. And --is it possible to have a bigger separation with the other 2 sections?
* No dealing with system config The user ideally should not have to deal at all with system-general config files, which also deal as geany defaults IIUC. Possible solution: In the latest versions, there are entries in the 'Tools' menu to allow editing some config files directly in geany itself. One of this entries allows editing filetypes.common; if the user version does not yet exist (in the user config folder), it is then created by copy (from the system config folder). Add one entry to edit user filetype config files. Do the same as for filetypes.common. To select the filetype: (1) a submenu like for setting the filetype (2) a popup with a rolling list (3) a popup with a text field to type the (case-insensitive) filetype name.
* Easy config of new filetype This would deal as recommended way to create a *new* filetype: open an existing one for edition in geany, save it at once as config file for the new filetype, edit it. There should be a standard one having the structure and entries with common sensible values, for cases when no appropriate model filetype exists (present filetypes.Geany.conf seems to be configured for Vala). Entries for which no sensible value exist should be present anyway, so that the user knows about them.
* No "filetypes.Lang.conf" Filetype config files should all have the same naming pattern. For a new language, instead of filetypes.Lang.conf, why not just filetypes.lang? In addition, having the name capitalised only for new filetypes is a source of annoying issues.
* Filetype config file names Better, also solve this: filetype config files are often edited in geany (else, other editors also have styling for common languages). Since the names of the config files end in the name of the languge, thjey are styled as if they were source code of this language, instead of just config files. Solution: reverse the logic, or rather reset it as should be: lang.cfg instead of filetypes.lang.
* no tweaking of filetype_extensions.conf Filetype extensions should be declared in the filetype config file. Actually, all the config for a filetype should be in a single file. I first thought there could be no filetype_extensions.conf at all, but this may force geany to read all filetype confg files at startup. Instead, there could a generated one, updated when filetype config files are edited in geany, or whenever geany detects a modif (by last edition time), or via the menu entry "Tools/Reload Configuration".
* config file doc Comments in config files may be rewtritten (they have improved, but still..). Some param names can be clearer. (Naming is doc.)
Denis
On 8 February 2012 03:29, spir denis.spir@gmail.com wrote:
On 02/06/2012 09:11 PM, Lex Trotman wrote:
PS Note there is a wiki entry on configuring the build system at http://wiki.geany.org/howtos/configurebuildmenu
First, thank you and bravo for this wiki page on the topic. It is great and above all clear. Reading it not only helped but also launched a few comments to possibly still ameliorate the system on details, and a 2 questions on remaining obscure points. If ever I finally understand things well enough, I'll help and improve the wiki page.
Yes, please help explaining, but please check proposed changes here first, it annoys the wiki administrator having to revert erroneous changes.
Also add one on settings for Go, and possibly a general one on how to introduce a new language (this badly lacks in geany doc).
New wiki pages are welcome.
*** Questions ***
- toolbar buttons?
The relation between the build menu config (either in files or via GUI) and toolbar is unclear for me. I guess --because it seems to work that way on my machine-- that ~ If ever, resulting from config, there are "Compile" & "Build" entries in the 1st section of the menu, then they map to matching buttons.
Yes
~ The Execute button's command is always set by the Execute line of the menu, meaning in config the first line of the fourth section.
Yes
If true, then I find that difficult to get. I tried both in files and through GUI to set an Execute command, like the Compile & Build ones, which doubled the predefined one without any effect. Conversely, why is there no predefined entries for the Compile & Build like for Execute? Sure, they do not apply to interpreted languages, but the entries could still be there, no?
Useless entries are not shown in the menu, if the filetype of the current file does not set commands none are shown.
- Relation between config files & GUI settings?
What happens to the config after changing settings on the GUI. They double the files' role. What kind of relation are there between GUI setting and config files, in both relations?
The GUI settings save over the same setting in the user config files or the project config files.
Who wins?
No one "wins" you are editing the same config file, just you have two ways of doing it, with an editor or with the GUI.
The page pointed above lists the "cascade" of config locations in files, but does not include the GUI settings.
Thats because the GUI edits the config files, thats how its included, see the manual for a table http://www.geany.org/manual/current/index.html#build-menu-configuration
Conversely, what happens to the GUI settings after changing files? I think we may do without these GUI that double and complicate the config system. Simply, the config files would as standard propose parameter lines equivalent to the present GUI, and the doc would state that it is recommended to stop there. ("With power comes responsability")
Not acceptable for new users. The usual request is for more GUI editing not less.
*** Comments ***
- Build Menu orga
It may be reorganised so that the 3 configurable sections (out of 5) come 1st, 2nd, 3rd. And --is it possible to have a bigger separation with the other 2 sections?
The organisation has been the same for a long time, you would have to have a good argument to change it. (and probably expect to be flamed on the ML, users get *so* attached to their GUIs) I wasn't around when it was first proposed, but as I say in the wiki, I believe it is laid out in the order of the usual C workflow, compile/link one file, make a whole lot of files, search for the errors, execute the result if no errors. And prefs is last as usual.
- No dealing with system config
The user ideally should not have to deal at all with system-general config files, which also deal as geany defaults IIUC. Possible solution: In the latest versions, there are entries in the 'Tools' menu to allow editing some config files directly in geany itself. One of this entries allows editing filetypes.common; if the user version does not yet exist (in the user config folder), it is then created by copy (from the system config folder). Add one entry to edit user filetype config files. Do the same as for filetypes.common. To select the filetype: (1) a submenu like for setting the filetype (2) a popup with a rolling list (3) a popup with a text field to type the (case-insensitive) filetype name.
Yes, extending the menu to the other config files is likely to be useful, patches welcome.
- Easy config of new filetype
This would deal as recommended way to create a *new* filetype: open an existing one for edition in geany, save it at once as config file for the new filetype, edit it. There should be a standard one having the structure and entries with common sensible values, for cases when no appropriate model filetype exists (present filetypes.Geany.conf seems to be configured for Vala). Entries for which no sensible value exist should be present anyway, so that the user knows about them.
1. if making a custom filetype (which is based on an existing one) you would copy the existing filetype as a start 2. if making a completely new filetype there is no prototype, it depends on what capabilities the lexer in Scintilla exposes and how they are mapped to the config file.
- No "filetypes.Lang.conf"
Filetype config files should all have the same naming pattern. For a new language, instead of filetypes.Lang.conf, why not just filetypes.lang? In addition, having the name capitalised only for new filetypes is a source of annoying issues.
You can call your custom language anything, up to you, but since it is displayed it is better to use a name with capitalisation. For builtin types there is an internal mapping to the displayname, so they use lower case, but for custom filetypes it always has to be the same so that Geany can relate settings in filetypes.extensions to the language etc.
Custom filetypes have a conf extension so that they get the right filetype (.conf) when opened by Geany. It would be nice if the built-in filetypes did the same, I am often annoyed by Geany trying to format filetypes.c as a C file, but it would be hard to change and remain backwardly compatible with all the existing edited filetypes.lang files in user directories.
- Filetype config file names
Better, also solve this: filetype config files are often edited in geany (else, other editors also have styling for common languages). Since the names of the config files end in the name of the languge, thjey are styled as if they were source code of this language, instead of just config files. Solution: reverse the logic, or rather reset it as should be: lang.cfg instead of filetypes.lang.
See above.
- no tweaking of filetype_extensions.conf
Filetype extensions should be declared in the filetype config file.
You find the config file by looking up the language name in filetype_extensions.conf. Geany does *not* read all the language definition files, only the ones needed for open files.
Actually, all the config for a filetype should be in a single file. I first thought there could be no filetype_extensions.conf at all, but this may force geany to read all filetype confg files at startup. Instead, there could a generated one, updated when filetype config files are edited in geany, or whenever geany detects a modif (by last edition time), or via the menu entry "Tools/Reload Configuration".
This would still require Geany to look at all the config files to see which ones had changed, ok its stating it not loading it, but you would have to keep doing it.
- config file doc
Comments in config files may be rewtritten (they have improved, but still..).
Patches are welcome :)
Some param names can be clearer. (Naming is doc.)
Provide suggestions, being aware that backward compatibility needs to be kept as much as possible.
Denis
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 02/07/2012 10:00 PM, Lex Trotman wrote:
On 8 February 2012 03:29, spirdenis.spir@gmail.com wrote:
On 02/06/2012 09:11 PM, Lex Trotman wrote:
PS Note there is a wiki entry on configuring the build system at http://wiki.geany.org/howtos/configurebuildmenu
First, thank you and bravo for this wiki page on the topic. It is great and above all clear. Reading it not only helped but also launched a few comments to possibly still ameliorate the system on details, and a 2 questions on remaining obscure points. If ever I finally understand things well enough, I'll help and improve the wiki page.
Yes, please help explaining, but please check proposed changes here first, it annoys the wiki administrator having to revert erroneous changes.
Right. Anyway i need to be sure i understand properly.
Also add one on settings for Go, and possibly a general one on how to introduce a new language (this badly lacks in geany doc).
New wiki pages are welcome.
Right (they don't break existing stuff ;-)
*** Questions ***
[... all fine, thanks for your clear answers ...]
*** Comments ***
- Build Menu orga
It may be reorganised so that the 3 configurable sections (out of 5) come 1st, 2nd, 3rd. And --is it possible to have a bigger separation with the other 2 sections?
The organisation has been the same for a long time, you would have to have a good argument to change it. (and probably expect to be flamed on the ML, users get *so* attached to their GUIs) I wasn't around when it was first proposed, but as I say in the wiki, I believe it is laid out in the order of the usual C workflow, compile/link one file, make a whole lot of files, search for the errors, execute the result if no errors. And prefs is last as usual.
Right.
- No dealing with system config
The user ideally should not have to deal at all with system-general config files, which also deal as geany defaults IIUC. Possible solution: In the latest versions, there are entries in the 'Tools' menu to allow editing some config files directly in geany itself. One of this entries allows editing filetypes.common; if the user version does not yet exist (in the user config folder), it is then created by copy (from the system config folder). Add one entry to edit user filetype config files. Do the same as for filetypes.common. To select the filetype: (1) a submenu like for setting the filetype (2) a popup with a rolling list (3) a popup with a text field to type the (case-insensitive) filetype name.
Yes, extending the menu to the other config files is likely to be useful, patches welcome.
This would be very nice.
- Easy config of new filetype
This would deal as recommended way to create a *new* filetype: open an existing one for edition in geany, save it at once as config file for the new filetype, edit it. There should be a standard one having the structure and entries with common sensible values, for cases when no appropriate model filetype exists (present filetypes.Geany.conf seems to be configured for Vala). Entries for which no sensible value exist should be present anyway, so that the user knows about them.
- if making a custom filetype (which is based on an existing one)
you would copy the existing filetype as a start
- if making a completely new filetype there is no prototype, it
depends on what capabilities the lexer in Scintilla exposes and how they are mapped to the config file.
Sorry, I was unclear. I was referring to the point above, the ability to edit filetype config files from within geany, with transparent copy to the user config dir if not yet existing: To create a new filetype, it is clearly good practice to copy from an existing one. Instead of explicitely copying from the system-wide config files, as we do now, using the above feature we could just open the existing filetype config file inside geany, and save it under the proper name for the new filetype. (The only issue beeing the difference in naming scheme for custom filetypes, evoked below, but that's independent.)
- No "filetypes.Lang.conf"
Filetype config files should all have the same naming pattern. For a new language, instead of filetypes.Lang.conf, why not just filetypes.lang? In addition, having the name capitalised only for new filetypes is a source of annoying issues.
You can call your custom language anything, up to you, but since it is displayed it is better to use a name with capitalisation. For builtin types there is an internal mapping to the displayname, so they use lower case, but for custom filetypes it always has to be the same so that Geany can relate settings in filetypes.extensions to the language etc.
Right.
Custom filetypes have a conf extension so that they get the right filetype (.conf) when opened by Geany. It would be nice if the built-in filetypes did the same, I am often annoyed by Geany trying to format filetypes.c as a C file, but it would be hard to change and remain backwardly compatible with all the existing edited filetypes.lang files in user directories.
Right ;-)
- Filetype config file names
Better, also solve this: filetype config files are often edited in geany (else, other editors also have styling for common languages). Since the names of the config files end in the name of the languge, thjey are styled as if they were source code of this language, instead of just config files. Solution: reverse the logic, or rather reset it as should be: lang.cfg instead of filetypes.lang.
See above.
Pleased to see I'm not the only one.
- no tweaking of filetype_extensions.conf
Filetype extensions should be declared in the filetype config file.
You find the config file by looking up the language name in filetype_extensions.conf. Geany does *not* read all the language definition files, only the ones needed for open files.
Actually, all the config for a filetype should be in a single file. I first thought there could be no filetype_extensions.conf at all, but this may force geany to read all filetype confg files at startup. Instead, there could a generated one, updated when filetype config files are edited in geany, or whenever geany detects a modif (by last edition time), or via the menu entry "Tools/Reload Configuration".
This would still require Geany to look at all the config files to see which ones had changed, ok its stating it not loading it, but you would have to keep doing it.
Is it a big deal at startup to review the time stamps of files filetypes.* in ~/.config/geany/filedefs, and extract an "extension=*.x" line for the ones having changed? (I'm really asking, not making bad spirit.) Since I'm learning Go, I may find the time to do it as an exercise, i have not yet touched the os or fs packages ;-) (You would just have to translate back the routine to C or c++ --I don't even know in what lang geany is coded!)
- config file doc
Comments in config files may be rewtritten (they have improved, but still..).
Patches are welcome :)
Some param names can be clearer. (Naming is doc.)
Provide suggestions, being aware that backward compatibility needs to be kept as much as possible.
You know, I have stopped to do that for a while already, because it is depressive experience to do sincere and durable efforts for the common good (after such suggestions as yours) and never see your work into the product, or 1% of it, or 3 years later. Guess you see what I mean... Reason why I love wikis. Geany's doc could be a wiki --not only additional texts such as your guide for the build menu. But it's only me, indeed.
Denis
[...]
Sorry, I was unclear. I was referring to the point above, the ability to edit filetype config files from within geany, with transparent copy to the user config dir if not yet existing: To create a new filetype, it is clearly good practice to copy from an existing one. Instead of explicitely copying from the system-wide config files, as we do now, using the above feature we could just open the existing filetype config file inside geany, and save it under the proper name for the new filetype. (The only issue beeing the difference in naming scheme for custom filetypes, evoked below, but that's independent.)
Well, it isn't *that* hard to open the system config file and save-as in the user config directory, you shouldn't be doing it that often, edit your build commands in the GUI and now stop fiddling with the colours and get on with your work :-D
Thats why its not a high priority.
[...]
- no tweaking of filetype_extensions.conf
Filetype extensions should be declared in the filetype config file.
You find the config file by looking up the language name in filetype_extensions.conf. Geany does *not* read all the language definition files, only the ones needed for open files.
Actually, all the config for a filetype should be in a single file. I first thought there could be no filetype_extensions.conf at all, but this may force geany to read all filetype confg files at startup. Instead, there could a generated one, updated when filetype config files are edited in geany, or whenever geany detects a modif (by last edition time), or via the menu entry "Tools/Reload Configuration".
This would still require Geany to look at all the config files to see which ones had changed, ok its stating it not loading it, but you would have to keep doing it.
Is it a big deal at startup to review the time stamps of files filetypes.* in ~/.config/geany/filedefs, and extract an "extension=*.x" line for the ones having changed? (I'm really asking, not making bad spirit.)
Geany is used in lots of situations, including a number where home directories are on network shares, not local drives. So checking the modification dates of a lot of files is also likely to be slower than on local drives. Geany already does quite a lot on startup it doesn't seem worth it to slow it down to check for something that isn't going to change much and for no benefit to most users.
Since I'm learning Go, I may find the time to do it as an exercise, i have not yet touched the os or fs packages ;-) (You would just have to translate back the routine to C or c++ --I don't even know in what lang geany is coded!)
POC, plain old C
- config file doc
Comments in config files may be rewtritten (they have improved, but still..).
Patches are welcome :)
Some param names can be clearer. (Naming is doc.)
Provide suggestions, being aware that backward compatibility needs to be kept as much as possible.
In fact on further reflection I will make this stronger, there is no way we can change existing names because of the backward compatibility issues without far too much effort.
You know, I have stopped to do that for a while already, because it is depressive experience to do sincere and durable efforts for the common good (after such suggestions as yours) and never see your work into the product, or 1% of it, or 3 years later. Guess you see what I mean...
That happens, Geany is pretty slow to incorporate patches, we only have a small team, all volunteers, and they have other things they want to do, and some even have lives.
Reason why I love wikis. Geany's doc could be a wiki --not only additional texts such as your guide for the build menu. But it's only me, indeed.
The help can't be a wiki since it has to be distributed with Geany, it isn't reasonable to require a network connection to get the manual from help.
Cheers Lex