Hi all plugin authors, I've just merged plugin keybindings support into the trunk. This allows plugins to add configurable keybindings which are set just like Geany keybindings.
To do this it was necessary to break the keybinding commands into groups, so the plugin API has now broken for any plugins using p_keybindings->send_command(). The good news is that by grouping keybindings the plugin ABI can stay stable when we add any keybindings to the core.
For the details on how to add keybindings to your plugins please see plugins/htmlchars.c, and post here if you need more information.
Basically you use the new PLUGIN_KEY_GROUP macro to declare a keybinding group, then initialize each keybinding in init() using p_keybindings->set_item(plugin_key_group, ...)
Regards, Nick
On Wed, Mar 12, 2008 at 12:30 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
I've just merged plugin keybindings support into the trunk.
Excellent!!!
I hooked this API up to the Lua plugin, and already it is working!
Now users can list a few of their favorite scripts in ~/.geany/plugins/geanylua/hotkeys.cfg and the entries will show up in Geany's Edit->Preferences->Keybindings window.
But that leaves me with some questions...
Since the number of bindings needs to be pre-determined at compile time, I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Also, I need to allow for the possibility that some users won't have any scripts assigned, and others might have less than the maximum. So that leaves me with some potentially empty KeyBinding structures. I don't see where this would be a problem except that g_key_file_set_string() complains about NULL key names, so at the very least the name field needs to have some value.
So for the empty entries, I can just do something like:
p_keybindings->set_item(plugin_key_group, 5, NULL, 0, 0, "lua_key_5", NULL, NULL);
That seems to work fine, except that I end up with blank rows in the Edit->Preferences->Keybindings window.
So I wonder if it would be OK to change the init_keybindings() in geany/src/prefs.c to show only enries with non-null labels, e.g:
+ if ( kb->label != NULL ) + { key_string = gtk_accelerator_name(kb->key, kb->mods); gtk_tree_store_append(store, &iter, &parent); gtk_tree_store_set(store, &iter, KB_TREE_ACTION, kb->label, KB_TREE_SHORTCUT, key_string, KB_TREE_INDEX, i, -1); g_free(key_string); + }
Also (slightly off topic) I noticed that the htmlchars plugin behaves badly when it is unloaded/reloaded from the plugin manager.
It needs this line at the end of cleanup() + sc_dialog = NULL;
- Jeff
On Thu, 13 Mar 2008 04:43:54 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Wed, Mar 12, 2008 at 12:30 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
I've just merged plugin keybindings support into the trunk.
Excellent!!!
I hooked this API up to the Lua plugin, and already it is working!
Great ;-)
Now users can list a few of their favorite scripts in ~/.geany/plugins/geanylua/hotkeys.cfg and the entries will show up in Geany's Edit->Preferences->Keybindings window.
But that leaves me with some questions...
Since the number of bindings needs to be pre-determined at compile time, I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Thanks for bringing this up ;-)
Although the usual way using PLUGIN_KEY_GROUP requires a fixed number of keybindings, it should be possible to set any number by declaring plugin_key_group[] yourself and initializing it in init().
I'm just updating the doxygen plugin docs (work in progress, make -C doc api-doc) as follows:
"@code KeyBindingGroup plugin_key_group[1] @endcode Most plugins should use the PLUGIN_KEY_GROUP() macro to define it. However, its fields are not read until after init() is called for the plugin, so it is possible to setup a variable number of keybindings, e.g. based on the plugin's configuration file."
Hopefully your other points about NULL labels are now moot ;-) I'll answer the htmlchars bug in another email.
Regards, Nick
On Thu, Mar 13, 2008 at 8:00 AM, Nick Treleaven nick.treleaven@btinternet.com wrote:
Although the usual way using PLUGIN_KEY_GROUP requires a fixed number of keybindings, it should be possible to set any number by declaring plugin_key_group[] yourself and initializing it in init().
Cool, it worked.
Now I can change the maximum number of key bindings from 5 to 1,073,741,824 :-)
(Actually I think 10 should be enough)
Only one other problem - if the plugin has no keys assigned, just declaring plugin_key_group[1] still causes the name to appear in the Preferences window, even though it doesn't have any entries below it. Maybe prefs.c::init_keybindings() should skip adding the name when group->count is zero ?
Thanks, - Jeff
On Thu, 13 Mar 2008 10:21:32 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Now I can change the maximum number of key bindings from 5 to 1,073,741,824 :-)
;-)
Only one other problem - if the plugin has no keys assigned, just declaring plugin_key_group[1] still causes the name to appear in the Preferences window, even though it doesn't have any entries below it. Maybe prefs.c::init_keybindings() should skip adding the name when group->count is zero ?
An empty plugin_key_group is now ignored in SVN, thanks for reporting.
Regards, Nick
On Thu, Mar 13, 2008 at 12:18 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
An empty plugin_key_group is now ignored in SVN, thanks for reporting.
Man, you're quick! It's working now.
One other minor issue - I can now create the name and label strings dynamically, but I get those "discards qualifiers" messages when I compile with warnings turned on.
Would it be possible to remove the const qualifier from the gchar* fields in the KeyBinding and KeyBindingGroup structs, or does that cause warnings somewhere else?
Thanks, - Jeff
On Thu, 13 Mar 2008 13:52:49 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
One other minor issue - I can now create the name and label strings dynamically, but I get those "discards qualifiers" messages when I compile with warnings turned on.
Can you show some example code that produces the warnings, and your warning flags (I use at least -Wall and -Wextra)?
Would it be possible to remove the const qualifier from the gchar* fields in the KeyBinding and KeyBindingGroup structs, or does that cause warnings somewhere else?
Hmm, I'm not sure why that causes a problem. Maybe we can remove them, but I'd like to see the code first.
Regards, Nick
Nick Treleaven nick.treleaven@btinternet.com wrote:
Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
I can now create the name and label strings dynamically, but I get those "discards qualifiers" messages when I compile with warnings turned on.
Can you show some example code that produces the warnings, and your warning flags (I use at least -Wall and -Wextra)?
Here is an example that should give you a general idea of what I am trying to do. Note that I use "group" here instead of plugin_key_group[1] just to shorten lines for email...
/***************************/ #include "geany.h" #include "keybindings.h" #include "plugindata.h" #include "pluginmacros.h" PluginFields *plugin_fields; VERSION_CHECK(48) PLUGIN_INFO("ConstChar", "Warning", "0", "Jeff")
KeyBindingGroup plugin_key_group[1];
#define group plugin_key_group[1]
void init(GeanyData *data) { guint count=10; guint i; group.count=count; group.keys=g_new0(KeyBinding, count); for (i=0; i<count; i++) { group.keys[i].name=g_strdup_printf("key_%d",i); group.keys[i].name=g_strdup_printf("Label %d",i); } }
/* Destroy widgets */ void cleanup(void) { guint i; for (i=0; i<group.count; i++) { g_free(group.name); g_free(group.label); } g_free(group.keys); } /***************************/
The problem comes with calling g_free() on the const char* . You can get around it with a cast, but the warning comes back if you compile with -Wcast-qual .
- Jeff
Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
Minor copy/paste bug: - group.keys[i].name=g_strdup_printf("Label %d",i); + group.keys[i].label=g_strdup_printf("Label %d",i);
Funny how they never show up until after I press the "send" button :-)
- Jeff
On Fri, 14 Mar 2008 08:51:34 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Nick Treleaven nick.treleaven@btinternet.com wrote:
Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
I can now create the name and label strings dynamically, but I get those "discards qualifiers" messages when I compile with warnings turned on.
Can you show some example code that produces the warnings, and your warning flags (I use at least -Wall and -Wextra)?
Here is an example that should give you a general idea of what I am trying to do. Note that I use "group" here instead of plugin_key_group[1] just to shorten lines for email...
Thanks.
The problem comes with calling g_free() on the const char* . You can get around it with a cast, but the warning comes back if you compile with -Wcast-qual .
OK, I've now changed those fields to be char*, and updated keybindings_set_item() accordingly.
HTH, Nick
Nick Treleaven nick.treleaven@btinternet.com wrote:
OK, I've now changed those fields to be char*, and updated keybindings_set_item() accordingly.
Thank you!
- Jeff
On Thu, 13 Mar 2008 04:43:54 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Also (slightly off topic) I noticed that the htmlchars plugin behaves badly when it is unloaded/reloaded from the plugin manager.
It needs this line at the end of cleanup()
- sc_dialog = NULL;
Thanks, this might reveal some similar problems in other plugins. Since the plugin manager was added, it seems each GModule is loaded at startup, but not initialized. This means each plugin's global variables are only initialized at startup, not when they are enabled.
To solve this problem, it might be best to unload each module after reading the information for each plugin - this would be good to do anyway to save memory. Otherwise, the shared library must stay resident. Each plugin's metadata could be cached by Geany.
Regards, Nick
On Thu, 13 Mar 2008 13:10:37 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 13 Mar 2008 04:43:54 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Also (slightly off topic) I noticed that the htmlchars plugin behaves badly when it is unloaded/reloaded from the plugin manager.
It needs this line at the end of cleanup()
- sc_dialog = NULL;
Thanks, this might reveal some similar problems in other plugins. Since the plugin manager was added, it seems each GModule is loaded at startup, but not initialized. This means each plugin's global variables are only initialized at startup, not when they are enabled.
Not anymore ;-). This morning, I changed the code to only initialize "active" plugins. "active" means plugins which were enabled by the user. All other plugins are not read at all at startup of Geany but only if the plugin manager is loaded.
To solve this problem, it might be best to unload each module after reading the information for each plugin - this would be good to do anyway to save memory. Otherwise, the shared library must stay resident. Each plugin's metadata could be cached by Geany.
Hmm, since non-active plugins (now) are only initialized when opening the plugin manager, I suggest to unload the modules (of inactive plugins) when closing the plugin manager instead of caching the metadata.
Regards, Enrico
On Thu, 13 Mar 2008 14:36:26 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 13 Mar 2008 13:10:37 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Thanks, this might reveal some similar problems in other plugins. Since the plugin manager was added, it seems each GModule is loaded at startup, but not initialized. This means each plugin's global variables are only initialized at startup, not when they are enabled.
Not anymore ;-). This morning, I changed the code to only initialize "active" plugins. "active" means plugins which were enabled by the user. All other plugins are not read at all at startup of Geany but only if the plugin manager is loaded.
Cool, I hadn't checked latest SVN ;-)
To solve this problem, it might be best to unload each module after reading the information for each plugin - this would be good to do anyway to save memory. Otherwise, the shared library must stay resident. Each plugin's metadata could be cached by Geany.
Hmm, since non-active plugins (now) are only initialized when opening the plugin manager, I suggest to unload the modules (of inactive plugins) when closing the plugin manager instead of caching the metadata.
This would solve the problem of keeping modules resident in memory, but to fix the original global variable initialization problem, we also need to unload the module of any plugin disabled from the plugin manager, in case it is reloaded before the plugin manager is closed.
Regards, Nick
On Thu, 13 Mar 2008 14:00:54 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 13 Mar 2008 14:36:26 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 13 Mar 2008 13:10:37 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
Thanks, this might reveal some similar problems in other plugins. Since the plugin manager was added, it seems each GModule is loaded at startup, but not initialized. This means each plugin's global variables are only initialized at startup, not when they are enabled.
Not anymore ;-). This morning, I changed the code to only initialize "active" plugins. "active" means plugins which were enabled by the user. All other plugins are not read at all at startup of Geany but only if the plugin manager is loaded.
Cool, I hadn't checked latest SVN ;-)
To solve this problem, it might be best to unload each module after reading the information for each plugin - this would be good to do anyway to save memory. Otherwise, the shared library must stay resident. Each plugin's metadata could be cached by Geany.
Hmm, since non-active plugins (now) are only initialized when opening the plugin manager, I suggest to unload the modules (of inactive plugins) when closing the plugin manager instead of caching the metadata.
This would solve the problem of keeping modules resident in memory, but to fix the original global variable initialization problem, we also need to unload the module of any plugin disabled from the plugin manager, in case it is reloaded before the plugin manager is closed.
Oops, yes. And this would cause a rewrite of the already-loaded logic in the code ;-(.
Regards, Enrico
On Thu, 13 Mar 2008 15:19:16 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
To solve this problem, it might be best to unload each module after reading the information for each plugin - this would be good to do anyway to save memory. Otherwise, the shared library must stay resident. Each plugin's metadata could be cached by Geany.
Hmm, since non-active plugins (now) are only initialized when opening the plugin manager, I suggest to unload the modules (of inactive plugins) when closing the plugin manager instead of caching the metadata.
This would solve the problem of keeping modules resident in memory, but to fix the original global variable initialization problem, we also need to unload the module of any plugin disabled from the plugin manager, in case it is reloaded before the plugin manager is closed.
Oops, yes. And this would cause a rewrite of the already-loaded logic in the code ;-(.
Done in SVN r2355. Plugins now will be unloaded and afterwards loaded completely when toggled in the plugin manager. When the plugin state is "enabled" (toggled), then the plugin's init() function is called. This should solve the problem with static variables in plugins. I hope it works stable, I got tons of segfaults while changing the code ;-).
Regards, Enrico
On Mon, 17 Mar 2008 16:54:41 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Plugins now will be unloaded and afterwards loaded completely when toggled in the plugin manager. When the plugin state is "enabled" (toggled), then the plugin's init() function is called. This should solve the problem with static variables in plugins. I hope it works stable, I got tons of segfaults while changing the code ;-).
It seems fine so far ;-) And the bug with reloading the HTML chars plugin is now fixed.
Regards, Nick
On Thu, 13 Mar 2008 04:43:54 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
But that leaves me with some questions...
Since the number of bindings needs to be pre-determined at compile time, I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Well, I'm currently using twelve, no reason to think I won't need more than that in the future. I would hate to see a hard-coded limit imposed.
Thanks,
Steve
On Thu, Mar 13, 2008 at 10:28 AM, Steve steve@trinidadgraphics.com wrote:
Jeff Pohlmeyer wrote:
I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Well, I'm currently using twelve, no reason to think I won't need more than that in the future. I would hate to see a hard-coded limit imposed.
Hey, Steve -
Thanks for your input.
I believe you are right, 5 or 10 is probably way too conservative.
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
How does 100 sound?
- Jeff
On Thu, 13 Mar 2008 10:57:54 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Thu, Mar 13, 2008 at 10:28 AM, Steve steve@trinidadgraphics.com wrote:
Jeff Pohlmeyer wrote:
I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Well, I'm currently using twelve, no reason to think I won't need more than that in the future. I would hate to see a hard-coded limit imposed.
Hey, Steve -
Thanks for your input.
I believe you are right, 5 or 10 is probably way too conservative.
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
How does 100 sound?
Very reasonable. :)
Thanks,
Steve
On Thu, 13 Mar 2008 10:57:54 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Thu, Mar 13, 2008 at 10:28 AM, Steve steve@trinidadgraphics.com wrote:
Jeff Pohlmeyer wrote:
I currently allow for a maximum of five script bindings - Does that sound like a reasonable number?
Well, I'm currently using twelve, no reason to think I won't need more than that in the future. I would hate to see a hard-coded limit imposed.
Hey, Steve -
Thanks for your input.
I believe you are right, 5 or 10 is probably way too conservative.
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
Hehe, funny idea. I know people who are doing such things...and they get even paid to do so (alias software testers).
Regards, Enrico
2008/3/13, Enrico Tröger enrico.troeger@uvena.de:
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
Hehe, funny idea. I know people who are doing such things...and they get even paid to do so (alias software testers).
Users are not enemy to themselfs., usually they want working stuff, so they won't do such crazy thing. But if they want apache logs as keybinding files, why not? ;-) It is artificial limitation. Anyway you can't stop user who don't want his computer work from taking hammer and smashing evil device.
Best regards, Yura Siamshka
Yura Siamashka yurand2@gmail.com wrote:
2008/3/13, Enrico Tröger enrico.troeger@uvena.de:
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
Hehe, funny idea. I know people who are doing such things...and they get even paid to do so (alias software testers).
If there is money in crashing computers, I should be a millionaire :-)
Users are not enemy to themselfs., usually they want working stuff, so they won't do such crazy thing. But if they want apache logs as keybinding files, why not? ;-) It is artificial limitation.
Okay, now I am creating the bindings dynamically, and I set the "artificial limit" of 100 keybindings.
Anybody who can remember this many key combinations has a big enough brain to find MAX_HOT_KEYS=100 and change it to UINT_MAX if that's what they need.
Anyway you can't stop user who don't want his computer work from taking hammer and smashing evil device.
hehe, then they call tech support :-)
- Jeff
On Thu, 13 Mar 2008 14:23:22 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
But I do think we need some sort of limit, just in case someone accidentally copies their Apache log to the config file. :-0
Users are not enemy to themselfs., usually they want working stuff, so they won't do such crazy thing. But if they want apache logs as keybinding files, why not? ;-) It is artificial limitation.
Okay, now I am creating the bindings dynamically, and I set the "artificial limit" of 100 keybindings.
And/or maybe a warning could be useful to inform the user that there might be something wrong. Just an idea.
Regards, Enrico
On Wed, Mar 12, 2008 at 12:30 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi all plugin authors, For the details on how to add keybindings to your plugins please see plugins/htmlchars.c, and post here if you need more information.
Another thing I would like some clarification about - Toggling a plugin off/on in the plugin manager causes it to forget any saved keybinding settings. Which seems logical for a lot of cases, if you don't want the plugin enabled, then you probably don't want its settings cluttering up the config file. For plugins with only a couple of keybindings, this is not really a problem for the user to go back and reconfigure the settings.
But since people are already talking about 12+ keys for the Lua plugin, I hated to see this information lost without warning at the click of a checkbox, so I added some code to let the Lua plugin save it own keybindings to its own config file when it is unloaded. IMO, this is the best approach, if a plugin wants its keys saved when it is unloaded, then it is the responsibility of the plugin to save them.
Does anyone else feel differently?
- Jeff
On Mon, 17 Mar 2008 10:24:34 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Wed, Mar 12, 2008 at 12:30 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi all plugin authors, For the details on how to add keybindings to your plugins please see plugins/htmlchars.c, and post here if you need more information.
Another thing I would like some clarification about - Toggling a plugin off/on in the plugin manager causes it to forget any saved keybinding settings. Which seems logical for a lot of cases, if you don't want the plugin enabled, then you probably don't want its settings cluttering up the config file. For plugins with only a couple of keybindings, this is not really a problem for the user to go back and reconfigure the settings.
I've been meaning to add support for loading an individual plugin's keybindings when enabled in the plugin manager. I don't think it matters about keeping unloaded plugin's shortcuts in the keyfile really. I wasn't not sure whether it's necessary to save configured shortcuts when the user decides to unload a plugin (although there should at least be a warning somewhere).
But since people are already talking about 12+ keys for the Lua plugin, I hated to see this information lost without warning at the click of a checkbox, so I added some code to let the Lua plugin save it own keybindings to its own config file when it is unloaded. IMO, this is the best approach, if a plugin wants its keys saved when it is unloaded, then it is the responsibility of the plugin to save them.
Hmm, I don't really see it as the plugin's responsibility, perhaps it should be in the core. I don't like the idea of having some keybindings in Geany's keyfile and some in a plugin's keyfile, it doesn't seem a tidy solution.
Regards, Nick
Nick Treleaven nick.treleaven@btinternet.com wrote:
Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
if a plugin wants its keys saved when it is unloaded, then it is the responsibility of the plugin to save them.
Hmm, I don't really see it as the plugin's responsibility, perhaps it should be in the core. I don't like the idea of having some keybindings in Geany's keyfile and some in a plugin's keyfile, it doesn't seem a tidy solution.
No problem, i can easily rip that code back out of GeanyLua, I just want to know one way or the other...
- Jeff
On Mon, 17 Mar 2008 12:21:37 -0500 "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Nick Treleaven nick.treleaven@btinternet.com wrote:
Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
if a plugin wants its keys saved when it is unloaded, then it is the responsibility of the plugin to save them.
Hmm, I don't really see it as the plugin's responsibility, perhaps it should be in the core. I don't like the idea of having some keybindings in Geany's keyfile and some in a plugin's keyfile, it doesn't seem a tidy solution.
No problem, i can easily rip that code back out of GeanyLua, I just want to know one way or the other...
Plugin keybindings are now loaded and saved when toggling plugins from the plugin manager - so hopefully that code is unnecessary now.
Regards, Nick
On Mon, 17 Mar 2008 16:51:00 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
I've been meaning to add support for loading an individual plugin's keybindings when enabled in the plugin manager. I don't think it matters about keeping unloaded plugin's shortcuts in the keyfile really. I wasn't not sure whether it's necessary to save configured shortcuts when the user decides to unload a plugin (although there should at least be a warning somewhere).
If I recompile Geany, it won't load the GeanyLua plugin until it has been recompiled too. Then, Geany starts without loading GeanyLua, which has to be explicitly re-enabled with the plugin manager. The point is that Geany sometimes unloads your plugins whether you wish it so or not. That being the case, it seems to me to be fairly important that a plugin's configuration be retained somehow even if disabled or even if Geany rejects it. This happens now, because the script's shortcut is part of the script.
Is there a benefit in changing how Lua scripts set their shortcuts? The present arrangement is simple and works perfectly.
Regards,
Steve
Steve steve@trinidadgraphics.com wrote:
If I recompile Geany, it won't load the GeanyLua plugin until it has been recompiled too. Then, Geany starts without loading GeanyLua, which has to be explicitly re- enabled with the plugin manager. The point is that Geany sometimes unloads your plugins whether you wish it so or not. That being the case, it seems to me to be fairly important that a plugin's configuration be retained somehow even if disabled or even if Geany rejects it.
I agree, the settings should (and will) definitely be saved *somewhere*
This happens now, because the script's shortcut is part of the script. Is there a benefit in changing how Lua scripts set their shortcuts?
I think the new way will be less error-prone, less likely to conflict with other keybindings, and a little easier for me to explain and for newbies to understand.
Also, it just seems logical to follow the same convention as other plugins will.
The present arrangement is simple and works perfectly.
From what I have seen so far, both methods can co-exist
happily, so I don't see any reason to stop supporting the current system anytime soon.
Especially now, since 100% (1/1) of the users who have commented on this prefer to keep the existing method :-)
- Jeff
On Mon, 17 Mar 2008 13:15:26 -0600 Steve steve@trinidadgraphics.com wrote:
If I recompile Geany, it won't load the GeanyLua plugin until it has been recompiled too.
This is because at the moment we often have to break the plugin ABI in SVN. I'm assuming you mean after you update Geany.
Then, Geany starts without loading GeanyLua, which has to be explicitly re-enabled with the plugin manager.
Yes, I noticed this. I'm not sure why yet.
The point is that Geany sometimes unloads your plugins whether you wish it so or not. That being the case, it seems to me to be fairly important that a plugin's configuration be retained somehow
I don't think any plugin configuration does get lost. The keybindings only get lost at the moment if you set them without quitting Geany with the plugin still loaded. This will be fixed fairly soon.
Regards, Nick