Interaction between a plugin and its editor
Posted: Tue 04 Feb, 2014 17:13
I am looking for the "do's and dont's" of interacting between a plugin and its associated editor: Imagine a plugin which creates a temporary file with some content, opens an editor for this file, lets user do what he likes with the editor, and when the editor is closed, performs some actions on what was left in the temporary file (e.g. the frename.dll plugin for FAR1). I would like to provide some functionality for that editor window (e.g. "F8 -> add '.bak' to the target filename"). I am looking for suggestions on how best implement this:
a) Don't do anything at all, a user who wants a functionality can write a macro for it. This is obviously the easiest for me, but lacks functionality that I would like - e.g. the ability to only provide that functionality for my plugin's editors, not other editors where the functionality wouldn't be relevant, ability to react to the current state of the plugin, or the ability to display proper keyboard shortcuts in FAR's keybar.
b) Provide various functions that can be called from a macro (via OpenW's OPEN_FROMMACRO and OPEN_LUAMACRO). It seems to me this pretty much shares the disadvantages of a), with the extra disadvantage that only those able to write programs in FAR's macrolanguage would be able to make use of this ability of my plugin.
c) Allow the plugin to be opened from the editor (via OpenW's OPEN_EDITOR), providing various menu options to cover the available functionality. It would check whether the current editor "belongs" to the plugin and if so, perform an action (e.g. it would show a manu item "Add '.bak' to the target filename"). This would be easy to use for most users, they would simply record a macro (CTRL+.) which would press F11, my plugin's shortcut, the desider action's shortcut. The keybar could be modified by using EditorControl with ECTL_SETKEYBAR, if I understand the Encyclopedia correctly. But I don't see how I could prevent the menu from showing in any editor other than mine.
d) Intercept ProcessEditorInputW and react according to the plugin's/editor's state. This would be even easier to use than c), and I could react to a key only in my editors. But it would seem to slow down editors which don't belong to my plugin, even if just a little (as much as it takes to look up the editor's ID in the list of my plugin's opened editors).
e) Something else?
At the moment, I am inclined to use either c) or d), or possibly both. But perhaps I am overlooking some preferred possibility or some significant drawback. I would appreciate input from FAR and/or plugin developers regarding this issue.
Thanks.
a) Don't do anything at all, a user who wants a functionality can write a macro for it. This is obviously the easiest for me, but lacks functionality that I would like - e.g. the ability to only provide that functionality for my plugin's editors, not other editors where the functionality wouldn't be relevant, ability to react to the current state of the plugin, or the ability to display proper keyboard shortcuts in FAR's keybar.
b) Provide various functions that can be called from a macro (via OpenW's OPEN_FROMMACRO and OPEN_LUAMACRO). It seems to me this pretty much shares the disadvantages of a), with the extra disadvantage that only those able to write programs in FAR's macrolanguage would be able to make use of this ability of my plugin.
c) Allow the plugin to be opened from the editor (via OpenW's OPEN_EDITOR), providing various menu options to cover the available functionality. It would check whether the current editor "belongs" to the plugin and if so, perform an action (e.g. it would show a manu item "Add '.bak' to the target filename"). This would be easy to use for most users, they would simply record a macro (CTRL+.) which would press F11, my plugin's shortcut, the desider action's shortcut. The keybar could be modified by using EditorControl with ECTL_SETKEYBAR, if I understand the Encyclopedia correctly. But I don't see how I could prevent the menu from showing in any editor other than mine.
d) Intercept ProcessEditorInputW and react according to the plugin's/editor's state. This would be even easier to use than c), and I could react to a key only in my editors. But it would seem to slow down editors which don't belong to my plugin, even if just a little (as much as it takes to look up the editor's ID in the list of my plugin's opened editors).
e) Something else?
At the moment, I am inclined to use either c) or d), or possibly both. But perhaps I am overlooking some preferred possibility or some significant drawback. I would appreciate input from FAR and/or plugin developers regarding this issue.
Thanks.