When the setter method - setRerun: implemented as part of GlyphsFilter protocol is called for each filter plugin, for some reason NO always seems to be passed as the argument. Thus, at the moment there is no way for filter plugins to tell if it’s really a re-run or not.
It looks it reproduces both on Glyphs 2/3. Hope it’s addressed when you have time.
What are you playing to use this for? I don’t use it anymore myself. I think I planned to use it to not show the filter dialog on rerun but that is not useful.
Yep, I agree that it’s not that useful in the end. And thanks for explaining your original intention.
I was just reluctant to make a dialog to accept options, so I took a shortcut by testing [[[NSApplication sharedApplication] currentEvent] modifierFlags] & NSEventModifierFlagOption so that the alternative strategy can be activated in my filter implementation only when the Option key is being pressed. When Command + R is going to be pressed consecutively, I thought it should make more sense to re-use the same option as before, and that’s why I dug into the rerun property.
At this point, I ended up to use the following snippet
NSEvent *event = [[NSApplication sharedApplication] currentEvent];
BOOL rerun = ([event modifierFlags] & NSEventModifierFlagCommand) && [[event charactersIgnoringModifiers] isEqualToString:@"r"];
as a workaround to determine if it’s indented to be a re-run. That kind of scenario might not be common, so I started to think that leaving the property as it is would be reasonable. I just didn’t expect that the argument will always be false regardless of the re-run state.
Or add a second shortcut to your filter. This is less likely to collide with other shortcuts.
Yes, the problem I had was that the Option + Command + R combination collides with the one in the Script menu. Having multiple key equivalents in a single menu item is not possible AFAIK (without adding a hidden menu item), and I’m afraid pressing extra modifiers might not work for menu items. But anyway, thank you very much for the suggestion!
That’s why I suggested to use a custom shortcut for your filter+ the option variant.
And the Command+R action will not be triggered if you press any other modifier key. So looking at the event will not help you in this case (you could try with CTRL).
Thank you for the follow-up!
I found out that the technique I originally wanted to implement was described in the thread above. I know that’s a breeze in .xib, but the current filter plugin protocol is allowed to have only one dedicated menu item per plugin, so my assumption is that we can’t have an alternate menu item or multiple keyboard shortcuts (with modifier variations) unless we duplicate the plugin. It is technically possible to manipulate the main menu after the plugin has been loaded, but I would avoid that to keep my plugin concise.
I know filters are not meant to provide a menu item that behaves like Edit > Paste Special, so the current situation is completely okay for me, and my NSEvent-based hack is working nicely so far. Otherwise I should go implement a proper dialog!
You can add the second shortcut like so:
GSCallbackHandler.registerShortcutCommand_group_identifier_action_target_character_modifierFlags_(title, group, identifier, action, target, character, modifierFlags)
Thanks for the information, I didn’t notice that there was such a nice addition for Glyphs 3! The shortcut feature looks so powerful and extensible. I’ll definitely consider using it where it doesn’t need compatibility with Glyphs 2.
What a lovely mouthfull of a method name 
def __registerShortcutCommand__(self, title, group, identifier, action, target, character=None, modifierFlags=None):
GSCallbackHandler.registerShortcutCommand_group_identifier_action_target_character_modifierFlags_(title, group, identifier, action, target, character=None, modifierFlags)
GSApplication.registerShortcutCommand = python_method(__registerShortcutCommand__)
I expect the corresponding Python API like above will be added to GlyphsSDK when Georg feels it’s stable.
While off-topic, Kotlin/Native supports Swift-ish name translation for Objective-C methods. I suppose the whole interop will get more Pythonic (and less mouthful) by itself if it lands on PyObjC in future, and that’s what I’ve been wanting for ages…
He posted that a long time ago and nothing happens since then. He is mostly the only one working on PyObjC, so progress is slow.