Re: [platform-ui-dev] Macro recording capabilities

[Fabio Zadrozny <fabiofz@xxxxxxxxx>]

On Wed, Jan 18, 2017 at 3:57 PM, Brian de Alwis <briandealwis@xxxxxxxxx> wrote:

Hi Fabio.

Thanks for taking another stab at macros.  I think focusing on intra-editor behaviour makes sense.  The commands-based + SWT approach I took is pretty brittle.  I think you're proposing modifying the KeyBindingDispatcher to create some kind of object, put into the workbench's context, that allows participants to contribute to a macro.  So the AbstractTextEditor could turn an autocomplete into {INSERT "foo.bar()"}.

​Yes, that's exactly the idea ;)​

Implementation-wise, the idea is that there'll be an EMacroContext which users are able to @Inject and then they can check if(macroContext.isRecording()){ macroContext.addCommand(CustomCodeCompletionMacroCommand(...);)}.

In the case of the KeyBindingDispatcher, it'll check the EMacroContext.isRecording() to whitelist commands that go through and decide whether a command should be added for that (or just have it pass through and let its implementation record the side-effects, as would be the case of the code-completion in the example above).

As a note, I'll probably not really add the support on code completion initially (and will just blacklist it), but the underlying structure should already have everything needed to support that use case (although given that each editor can customize it greatly, it's possible that each editor will have to whitelist it to support recording its own code-completions on the macro recording).

 

The quote-autocomplete type preferences only seems to be an issue if you want to allow persisting macros (i.e., so a user with a different preference can replay the macro with the same results).  It seems unlikely the user will replay a macro with  different preferences, though I suppose they may replay on files from different projects with different settings.

As the idea is allow persisting of macros, I see such things becoming issues... an option could be persisting that information into the macro -- so a replay could go into that mode, play the macro and then restore the previous settings, but I'd say that I think having an editor always in a more "raw" state may make sense for macros (and it's also easier to get right initially, so, I'll start by implementing that).

At least on my use-cases, macro editions are usually related to making replacements on text on very specific places -- close to what happens in rectangular edition mode -- and usually don't need/want all the bells and whistles available... although having the find action should probably also be supported sooner rather than later (I'll initially block it to provide a shorter pull request which implements the structure I have in mind, but the idea will be adding it soon afterwards).

​Best Regards,

Fabio​