Fixup a006f71 #4 (plugins: add geany_plugin_register_proxy() to the p…

…lugin API)

inferior -> sub-plugin

Please squash

doc/plugins.dox

@@ -742,19 +742,19 @@ Geany provides a mechanism to enable support for those languages. Native plugins
 proxy plugins by being a normal plugin to the Geany-side and by providing a bridge to write plugins
 in another language on the other side.
 
-These plugins are also called sub-plugins or inferiors. This refers to the relation to their proxy.
+These plugins are also called sub-plugins. This refers to the relation to their proxy.
 To Geany they are first-class citizens.
 
 @section proxy_protocol Writing a Proxy Plugin
 
 The basic idea is that a proxy plugin provides methods to match, load and unload one or more
-inferior plugins in an abstract manner:
+sub-plugin plugins in an abstract manner:
 
  - Matching consists of providing a list of supported file extensions for the sub-plugins and
    a mechanism to resolve file extension uncertainty or ambiguity. The matching makes the plugin
    visible to the user within the Plugin Manager.
- - Loading consists of loading the inferior's file, passing the file to some form of interpreter
-   and calling GEANY_PLUGIN_REGISTER() or GEANY_PLUGIN_REGISTER_FULL() on behalf of the inferior
+ - Loading consists of loading the sub-plugin's file, passing the file to some form of interpreter
+   and calling GEANY_PLUGIN_REGISTER() or GEANY_PLUGIN_REGISTER_FULL() on behalf of the sub-plugin
    at some point.
  - Unloading simply reverses the effect of loading.
 
@@ -778,20 +778,20 @@ done in the GeanyPluginFuncs::init function of the proxy plugin.
    be called to register the sub-plugin.
  - GeanyProxyFuncs::unload must be implemented and is called when the user unchecks the sub-plugin
    or when Geany exits. Here, the proxy should release any references or memory associated to the
-   inferior. Note that if GeanyProxyFuncs::load didn't succeed, i.e. didn't successfully register
-   the inferior, then this function won't be called.
+   sub-plugin. Note that if GeanyProxyFuncs::load didn't succeed, i.e. didn't successfully register
+   the sub-plugin, then this function won't be called.
 
 GeanyProxyFuncs::load and GeanyProxyFuncs::unload receive two GeanyPlugin pointers: One that
-corresponds to the proxy itself and another that corresponds to the inferior. The inferior's
+corresponds to the proxy itself and another that corresponds to the sub-plugin. The sub-plugin's
 one may be used to call various API functions on behalf of the sub-plugin, including
 GEANY_PLUGIN_REGISTER() and GEANY_PLUGIN_REGISTER_FULL().
 
 GeanyProxyFuncs::load may return a pointer that is passed back to GeanyProxyFuncs::unload. This can
-be used to store proxy-defined but inferior-specific data required for unloading. However, this
-pointer is not passed to the inferior's GeanyPluginFuncs. To arrange for that, you want to call
+be used to store proxy-defined but sub-plugin-specific data required for unloading. However, this
+pointer is not passed to the sub-plugin's GeanyPluginFuncs. To arrange for that, you want to call
 GEANY_PLUGIN_REGISTER_FULL(). This method is the key to enable proxy plugins to wrap the
-GeanyPluginFuncs of all sub-plugins and yet multiplex between multiple inferior, for example by
-storing a per-inferior interpreter context.
+GeanyPluginFuncs of all sub-plugins and yet multiplex between multiple sub-plugin, for example by
+storing a per-sub-plugin interpreter context.
 
 @note If the pointer returned from GeanyProxyFuncs::load is the same that is passed to
 GEANY_PLUGIN_REGISTER_FULL() then you must pass NULL as free_func, because that would be invoked
@@ -860,8 +860,9 @@ Therefore, if possible, try to fail fast and disallow registration.
 @section Proxy Plugin Example
 
 In this section a dumb example proxy plugin is shown in order to give a practical starting point.
-The sub-plugin are not actually code but rather a INI-style description of one or more menu items
-that are added to Geany's tools menu and a help dialog.
+The sub-plugin are not actually code but rather a ini-style description of one or more menu items
+that are added to Geany's tools menu and a help dialog. Real world sub-plugins would contain actual
+code, usually written in a scripting language.
 
 A sub-plugin file looks like this:
 
@@ -970,13 +971,13 @@ static gint demoproxy_probe(GeanyPlugin *proxy, const gchar *filename, gpointer
 }
 @endcode
 
-GeanyProxyFuncs::load is a bit more complex. It reads the file, fills the inferior's PluginInfo
+GeanyProxyFuncs::load is a bit more complex. It reads the file, fills the sub-plugin's PluginInfo
 fields and calls GEANY_PLUGIN_REGISTER_FULL(). Additionally, it creates a per-plugin context that
 holds GKeyFile instance (a poor man's interpeter context). You can also see that it does not call
 GEANY_PLUGIN_REGISTER_FULL() if g_key_file_load_from_file() found an error (probably a syntax
 problem) which means the sub-plugin cannot be enabled.
 
-It also installs wrapper functions for the inferior's GeanyPluginFuncs as Ini files aren't code.
+It also installs wrapper functions for the sub-plugin's GeanyPluginFuncs as ini files aren't code.
 It's very likely that your proxy needs something similar because you can only install function
 pointers to native code.
 
@@ -1050,7 +1051,7 @@ Finally the demo_proxy's wrapper GeanyPluginFuncs. They are called for each poss
 therefore have to multiplex between each using the plugin-defined data pointer. Each is called by
 Geany as if it were an ordinary, native plugin.
 
-proxy_init() actually reads the inferior's file using GKeyFile APIs. It prepares for the help
+proxy_init() actually reads the sub-plugin's file using GKeyFile APIs. It prepares for the help
 dialog and installs the menu items. proxy_help() is called when the user clicks the help button in
 the Plugin Manager. Consequently, this fires up a suitable dialog, although with a dummy message.
 proxy_cleanup() frees all memory allocated in proxy_init().