Page 1 of 1

Interaction between a plugin and its editor

Posted: Tue 04 Feb, 2014 17:13
by pepak
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.

Re: Interaction between a plugin and its editor

Posted: Tue 04 Feb, 2014 17:34
by NightRoman
c) ... But I don't see how I could prevent the menu from showing in any editor other than mine.
In GetPluginInfoW can you check the current editor? If it does not "belong" to the plugin then do not return info about the menu. Otherwise return info about the menu. Will this work?

Re: Interaction between a plugin and its editor

Posted: Wed 05 Feb, 2014 06:07
by pepak
As I understand GetPluginInfoW, it gets called once and that's it. The plugin has to decide whether it can be called from an editor (any editor) at that time. (Though apparently I don't understand everything about GetPluginInfoW, because I don't see how to get a different menu when called from Shell and a different menu when called from Editor, as RESearch does.)

Re: Interaction between a plugin and its editor

Posted: Wed 05 Feb, 2014 06:55
by NightRoman
As I understand GetPluginInfoW, it gets called once and that's it.
No, it is called every time when a menu is needed.

Take a look at my AsGetPluginInfo (wrapper of GetPluginInfoW) here:
https://code.google.com/p/farnet/source ... n/Far0.cpp

It's C++/CLI and it contains some external method calls but it should give you an idea. It's from the plugin FarNet. Its menu depends on the current area and it is dynamic, i.e. also depends on (several) FarNet module menus.

Re: Interaction between a plugin and its editor

Posted: Wed 05 Feb, 2014 10:34
by John Doe
pepak wrote:a)...
b)...
User do not have to write macros, you can write it yourself.
There are 2 ways:
1) Put ready to use macrofile with your plugin
2) Make temporary macros in runtime (MCTL_ADDMACRO)
pepak wrote: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
It is all possible with Plugin.Call and other macro functions.

Re: Interaction between a plugin and its editor

Posted: Thu 06 Feb, 2014 06:56
by pepak
NightRoman wrote:
As I understand GetPluginInfoW, it gets called once and that's it.
No, it is called every time when a menu is needed.
Take a look at my AsGetPluginInfo (wrapper of GetPluginInfoW) here:
https://code.google.com/p/farnet/source ... n/Far0.cpp[/quote]
Very nice. Thanks!!

Re: Interaction between a plugin and its editor

Posted: Thu 06 Feb, 2014 06:58
by pepak
John Doe wrote:User do not have to write macros, you can write it yourself.
There are 2 ways:
1) Put ready to use macrofile with your plugin
2) Make temporary macros in runtime (MCTL_ADDMACRO)
My concern is mostly whether the macro approach is preferred to the plugin approach, or the other way around.
pepak wrote: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
It is all possible with Plugin.Call and other macro functions.
That's way over my head, me having no experience with macro scripts at all, but I will keep it in mind.