Quantcast

Macro recording capabilities

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Macro recording capabilities

Fabio Zadrozny
Hi All,

I'm in the process of implementing macro recording capabilities (i.e.: https://bugs.eclipse.org/bugs/show_bug.cgi?id=8519) -- I already have some working code, but I thought it'd be nice to gather some feedback before actually submitting something.

So, first, I already took a good look at the existing engines. Namely the one in https://wiki.eclipse.org/E4/Macros and http://practicalmacro.sourceforge.net and ultimately decided on a different approach which does things a bit different (learning from the issues on those implementations)...

Now, IMHO it's not possible to create a separate plugin which can take full responsibility for recording keystrokes and playing them back in the hope that things will work reliably (both plugins try to make everything from the outside and have too many issues because of that).

Things break because editor plugins were not made with this in mind (so, for instance, adding a quote in the java editor automatically adds a new quote and a record/playback with both of the passed plugins will not work and things such as code completion will utterly break the macro too as it's not possible to play back considering that -- at least not until the actual code-completion knows about the current macro record state).

So, my idea is starting the other way around: the initial plan is entering in a "dumb" mode in the editor so that all which is done can be directly replayed without any surprises (i.e.: disable code-completion, smart insert mode and everything that could interfere with the macro), only let "whiletisted" actions go through and record keystrokes for a playback later on just for the editor.

After this is in place, and things work reliably at this level, it should be possible to expand it and allow more advanced things (such as code-completion, find, etc), but this will be done as a second step after the first one works reliably and things should be implemented in the actual level that does it (for instance, the find action should be responsible for issuing a find command to the macro engine when it does a find, not the other way around).

Now, for this to work, the idea is creating::

org.eclipse.e4.core.macros
org.eclipse.e4.ui.macros

and actually making changes in the AbstractTextEditor and KeyBindingDispatcher to be aware of the macros (so, those will be changed so that they are actually responsible for providing the record and playback for the respective components, and other components may decide to participate later on as needed).

So, hopefully you'll see this as a workable approach... feedback/ideas are welcome ;)

Best Regards,

Fabio

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Mickael Istria-5
On 01/15/2017 01:45 PM, Fabio Zadrozny wrote:
Hi All,
Hi Fabio,

Have you considered looking at how SWTBot does UI action recording ( https://wiki.eclipse.org/SWTBot/Generator ) ? I don't think it's the grain that's best for Platform macro implementaiton as it includes code-generation via a rules mechanism, but the way listener is set up and events are processed may be interesting to you.

Cheers,
--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Daniel Megert
In reply to this post by Fabio Zadrozny
> and actually making changes in the AbstractTextEditor

This sounds like it will be at a too high level. What about other editors or Controls that use StyledText?

Dani



From:        Fabio Zadrozny <[hidden email]>
To:        "Eclipse Platform UI component developers list." <[hidden email]>
Date:        15.01.2017 13:46
Subject:        [platform-ui-dev] Macro recording capabilities
Sent by:        [hidden email]




Hi All,

I'm in the process of implementing macro recording capabilities (i.e.: https://bugs.eclipse.org/bugs/show_bug.cgi?id=8519) -- I already have some working code, but I thought it'd be nice to gather some feedback before actually submitting something.

So, first, I already took a good look at the existing engines. Namely the one in https://wiki.eclipse.org/E4/Macrosand http://practicalmacro.sourceforge.netand ultimately decided on a different approach which does things a bit different (learning from the issues on those implementations)...

Now, IMHO it's not possible to create a separate plugin which can take full responsibility for recording keystrokes and playing them back in the hope that things will work reliably (both plugins try to make everything from the outside and have too many issues because of that).

Things break because editor plugins were not made with this in mind (so, for instance, adding a quote in the java editor automatically adds a new quote and a record/playback with both of the passed plugins will not work and things such as code completion will utterly break the macro too as it's not possible to play back considering that -- at least not until the actual code-completion knows about the current macro record state).

So, my idea is starting the other way around: the initial plan is entering in a "dumb" mode in the editor so that all which is done can be directly replayed without any surprises (i.e.: disable code-completion, smart insert mode and everything that could interfere with the macro), only let "whiletisted" actions go through and record keystrokes for a playback later on just for the editor.

After this is in place, and things work reliably at this level, it should be possible to expand it and allow more advanced things (such as code-completion, find, etc), but this will be done as a second step after the first one works reliably and things should be implemented in the actual level that does it (for instance, the find action should be responsible for issuing a find command to the macro engine when it does a find, not the other way around).

Now, for this to work, the idea is creating::

org.eclipse.e4.core.macros
org.eclipse.e4.ui.macros

and actually making changes in the AbstractTextEditor and KeyBindingDispatcher to be aware of the macros (so, those will be changed so that they are actually responsible for providing the record and playback for the respective components, and other components may decide to participate later on as needed).

So, hopefully you'll see this as a workable approach... feedback/ideas are welcome ;)

Best Regards,

Fabio_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny
In reply to this post by Mickael Istria-5
Hi Fabio,

​Hi Mickael,​

 
Have you considered looking at how SWTBot does UI action recording ( https://wiki.eclipse.org/SWTBot/Generator ) ? I don't think it's the grain that's best for Platform macro implementaiton as it includes code-generation via a rules mechanism, but the way listener is set up and events are processed may be interesting to you.

Thanks for the tip, just got its source code to take a look at how it does things.

Cheers,

Fabio

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny
In reply to this post by Daniel Megert

On Mon, Jan 16, 2017 at 8:06 AM, Daniel Megert <[hidden email]> wrote:
> and actually making changes in the AbstractTextEditor

This sounds like it will be at a too high level. What about other editors or Controls that use StyledText?

Dani

​Hi Dani,​

​Well, the idea is to extract utilities for record/playback so that they can be reused properly later on.

Initially my idea is making anything non-essential non-API, but as things go forward, there's definitely a bunch of utilities that can be made available for others to make things easier to setup for macro recording for other views/editors, although my plan is initially committing to getting the text editor stable for macro record/playback and then, on a second step, after those concepts are already validated and working properly, go on and extract things to make it easier for others to reuse as things are needed.

The important part is that the structure to make the record/playback will already be available for all editors/views (based on org.eclipse.e4.core.macros) and that the general approach is deemed a good approach (which in general means that each view/editor will have to take some steps to actually make it macro-aware -- i.e.: each action made will have to note that it's in record mode and will have to post commands for a playback later on -- IMHO, that's the only approach that can be made to reliably work -- i.e.: an action such as a finding text and replacing it should record an action with a "find xxx"/"replace selection with yyy" and not require the actual find/replace widget to be active for the playback... I think that https://sourceforge.net/projects/practicalmacro/ does a good job at that, but as it tries to do everything from the outside, in the end it's not actually reliable enough to be used, although it gets many things right).

Best Regards,

Fabio

 

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Daniel Megert
> The important part is that the structure to make the record/playback will already be available for all editors/views (based on org.eclipse.e4.core.macros) and that the general approach is deemed a good approach

Well, that seems to contradict that you have to make changes in the AbstractTextEditor as opposed to StyledText or view/editor parts.

Dani



From:        Fabio Zadrozny <[hidden email]>
To:        "Eclipse Platform UI component developers list." <[hidden email]>
Date:        16.01.2017 16:01
Subject:        Re: [platform-ui-dev] Macro recording capabilities
Sent by:        [hidden email]





On Mon, Jan 16, 2017 at 8:06 AM, Daniel Megert <daniel_megert@...> wrote:
> and actually making changes in the AbstractTextEditor

This sounds like it will be at a too high level. What about other editors or Controls that use StyledText?


Dani


​Hi Dani,​

​Well, the idea is to extract utilities for record/playback so that they can be reused properly later on.

Initially my idea is making anything non-essential non-API, but as things go forward, there's definitely a bunch of utilities that can be made available for others to make things easier to setup for macro recording for other views/editors, although my plan is initially committing to getting the text editor stable for macro record/playback and then, on a second step, after those concepts are already validated and working properly, go on and extract things to make it easier for others to reuse as things are needed.

The important part is that the structure to make the record/playback will already be available for all editors/views (based on org.eclipse.e4.core.macros) and that the general approach is deemed a good approach (which in general means that each view/editor will have to take some steps to actually make it macro-aware -- i.e.: each action made will have to note that it's in record mode and will have to post commands for a playback later on -- IMHO, that's the only approach that can be made to reliably work -- i.e.: an action such as a finding text and replacing it should record an action with a "find xxx"/"replace selection with yyy" and not require the actual find/replace widget to be active for the playback... I think that https://sourceforge.net/projects/practicalmacro/does a good job at that, but as it tries to do everything from the outside, in the end it's not actually reliable enough to be used, although it gets many things right).

Best Regards,

Fabio

 _______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny

On Mon, Jan 16, 2017 at 1:09 PM, Daniel Megert <[hidden email]> wrote:
> The important part is that the structure to make the record/playback will already be available for all editors/views (based on org.eclipse.e4.core.macros) and that the general approach is deemed a good approach

Well, that seems to contradict that you have to make changes in the AbstractTextEditor as opposed to StyledText or view/editor parts.

Sorry, I probably didn't express myself well... I meant it'd be available as in "it'll be possible for all editors/views to participate in the macro recording", not that it'll be automatically implemented for them and that they'd get it without doing any change on their part.

As a note, on the "why" part, the StyledText is unaware of things such as code-completion or smart-i​nsert, etc, which is why I think that the AbstractTextEditor is a better place for it (sure, putting a listener in the StyledText will still be required, but in the end, the AbstractTextEditor is the base for text editors, the StyledText is just an implementation detail of it -- so, in this case, the AbstractTextEditor is in the same level of any other part, not the StyledText, and thus, is responsible for making sure its controls have the proper recording capabilities).

Cheers,

Fabio



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Mickael Istria-5
On 01/16/2017 04:25 PM, Fabio Zadrozny wrote:
As a note, on the "why" part, the StyledText is unaware of things such as code-completion or smart-i​nsert, etc, which is why I think that the AbstractTextEditor is a better place for it (sure, putting a listener in the StyledText will still be required, but in the end, the AbstractTextEditor is the base for text editors, the StyledText is just an implementation detail of it -- so, in this case, the AbstractTextEditor is in the same level of any other part, not the StyledText, and thus, is responsible for making sure its controls have the proper recording capabilities).
In between TextEditors and StyledText, there's the ITextViewer which seems a better choice for what you're trying to implement.
Also, before implementing this, I'm unsure of the user story of doing key macro recording only in a text editor or field and not on the whole application. Bug 8519 is about mcros for the whole IDE, including keyboard shortcuts and so on. Can you please elaborate some actual user stories highlighting how this is valuable with current IDE for instance?
--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Daniel Megert
Also, before implementing this, I'm unsure of the user story of doing key macro recording only in a text editor or field and not on the whole application. Bug 8519 is about mcros for the whole IDE, including keyboard shortcuts and so on. Can you please elaborate some actual user stories highlighting how this is valuable with current IDE for instance?

+1.

Dani



From:        Mickael Istria <[hidden email]>
To:        [hidden email]
Date:        16.01.2017 16:35
Subject:        Re: [platform-ui-dev] Macro recording capabilities
Sent by:        [hidden email]




On 01/16/2017 04:25 PM, Fabio Zadrozny wrote:
As a note, on the "why" part, the StyledText is unaware of things such as code-completion or smart-i​nsert, etc, which is why I think that the AbstractTextEditor is a better place for it (sure, putting a listener in the StyledText will still be required, but in the end, the AbstractTextEditor is the base for text editors, the StyledText is just an implementation detail of it -- so, in this case, the AbstractTextEditor is in the same level of any other part, not the StyledText, and thus, is responsible for making sure its controls have the proper recording capabilities).
In between TextEditors and StyledText, there's the ITextViewer which seems a better choice for what you're trying to implement.
Also, before implementing this, I'm unsure of the user story of doing key macro recording only in a text editor or field and not on the whole application. Bug 8519 is about mcros for the whole IDE, including keyboard shortcuts and so on. Can you please elaborate some actual user stories highlighting how this is valuable with current IDE for instance?

--
Mickael Istria
Eclipse developer for
Red Hat Developers
My blog - My Tweets_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny
In reply to this post by Mickael Istria-5

In between TextEditors and StyledText, there's the ITextViewer which seems a better choice for what you're trying to implement.
Also, before implementing this, I'm unsure of the user story of doing key macro recording only in a text editor or field and not on the whole application. Bug 8519 is about mcros for the whole IDE, including keyboard shortcuts and so on. Can you please elaborate some actual user stories highlighting how this is valuable with current IDE for instance?

​Well, ITextViewer being only an interface can't really have such an implementation... and AbstractTextEditor is the first abstraction actually implementing it (which is why I'm targeting it) -- but maybe I just haven't understood what you meant by it (care to explain a bit more your suggestion?).

Also, my suggestion is that that the whole IDE will be able to have record/playback, not only the text editor (but, I have to start somewhere, so, providing it for the text editor will be the first step... and it's actually the most thing requested in bug 8519 if you take a look at its comments... the first comment is on textpad macro functionality, then, the comment #4, from Ed Burnette, gives another example also only with text and find, then #9 says about vi (same thing, just text)... so, if you read more about the comments, you can see that most of them are only for the macro record/playback within the text editor -- personally, it's one of the reasons I keep having to open notepad++... just to copy some text to it, record/playback macro and copy it back -- a bit annoying having to copy back and forth, but really helpful in many occasions).

So, there are many user stories in that bug for macro record/playback in the text editor AND it'll be possible to extend it later on to add the support for other views to record things in the whole IDE as you're saying.

Cheers,

Fabio





_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Mickael Istria-5
On 01/16/2017 05:04 PM, Fabio Zadrozny wrote:
Also, my suggestion is that that the whole IDE will be able to have record/playback, not only the text editor (but, I have to start somewhere, so, providing it for the text editor will be the first step... and it's actually the most thing requested in bug 8519 if you take a look at its comments... the first comment is on textpad macro functionality, then, the comment #4, from Ed Burnette, gives another example also only with text and find, then #9 says about vi (same thing, just text)... so, if you read more about the comments, you can see that most of them are only for the macro record/playback within the text editor -- personally, it's one of the reasons I keep having to open notepad++... just to copy some text to it, record/playback macro and copy it back -- a bit annoying having to copy back and forth, but really helpful in many occasions).
This one uses a keyboard shortcut also. The shortcut changes text, for sure, but the request of the user is more to have the combination of text edit AND keyboard shortcut in a macro, it's not only text editor. There is no guarantee that the shortcuts affects text only and many commands/shortcuts do more than editing text in Eclipse IDE.

I have the impression the vast majority of them want also to invoke a command or a shortcut in combination with plain text edition. Ability to record shortcut+text editions seems to be a must-have for successful macro record/playback. If you want a consistent recorder, you'll probably have to put it at the SWT layer to make sure you can properly handle text edits and shortcuts and menus...
So, there are many user stories in that bug for macro record/playback in the text editor AND it'll be possible to extend it later on to add the support for other views to record things in the whole IDE as you're saying.
My experience with SWTBot recorder is that it's really worth hitting the lowest level possible (SWT) to record events and actions.If the recorder hits a level too high right now and misses to handle shortcuts, menus... later, this can invalidate the whole implementation and require a full rewrite on a lower level.
The playback part can easily be changed and replaced.

HTH
--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets

_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny
On Mon, Jan 16, 2017 at 2:21 PM, Mickael Istria <[hidden email]> wrote:
On 01/16/2017 05:04 PM, Fabio Zadrozny wrote:
Also, my suggestion is that that the whole IDE will be able to have record/playback, not only the text editor (but, I have to start somewhere, so, providing it for the text editor will be the first step... and it's actually the most thing requested in bug 8519 if you take a look at its comments... the first comment is on textpad macro functionality, then, the comment #4, from Ed Burnette, gives another example also only with text and find, then #9 says about vi (same thing, just text)... so, if you read more about the comments, you can see that most of them are only for the macro record/playback within the text editor -- personally, it's one of the reasons I keep having to open notepad++... just to copy some text to it, record/playback macro and copy it back -- a bit annoying having to copy back and forth, but really helpful in many occasions).
This one uses a keyboard shortcut also. The shortcut changes text, for sure, but the request of the user is more to have the combination of text edit AND keyboard shortcut in a macro, it's not only text editor. There is no guarantee that the shortcuts affects text only and many commands/shortcuts do more than editing text in Eclipse IDE.

I have the impression the vast majority of them want also to invoke a command or a shortcut in combination with plain text edition. Ability to record shortcut+text editions seems to be a must-have for successful macro record/playback. If you want a consistent recorder, you'll probably have to put it at the SWT layer to make sure you can properly handle text edits and shortcuts and menus...
So, there are many user stories in that bug for macro record/playback in the text editor AND it'll be possible to extend it later on to add the support for other views to record things in the whole IDE as you're saying.

​​Agreed... in my first message I already pointed that I'll make "changes in the AbstractTextEditor and KeyBindingDispatcher to be aware of the macros"​. 
My experience with SWTBot recorder is that it's really worth hitting the lowest level possible (SWT) to record events and actions.If the recorder hits a level too high right now and misses to handle shortcuts, menus... later, this can invalidate the whole implementation and require a full rewrite on a lower level.
The playback part can easily be changed and replaced.

I think my experience differs here... usually a full record/playback of the UI (such as swtbot, squish, pyautogui)​ is too brittle to be useful and will usually fail by many things later on just because something in the UI changed or the user interacted with the screen (which I'm considering is not acceptable for a macro/playback engine inside of a product such as Eclipse). It shouldn't deal with any menu or other UI element and should record the effects of the action the user did (as in my previous example of the replace/find, it shouldn't record the Ctrl+F and hit of the Find in the dialog and later hit on the replace, but actually record a "find text" action and a "replace text" action to be played back later on).

For instance, swtbot uses Display.post() for playing back -- but this just doesn't work at all for something which should be not brittle... i.e.: I went on to debug a record/playback with that API and it started playing back in a different instance of Eclipse (the one that was debugging the other one which should be the target just because that one lost focus and this one gained it) -- also see: http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg08180.html, so, I think such a solution is simply unworkable for a reliably record/playback engine.

Cheers,

Fabio



_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Brian de Alwis-3
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()"}.

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.

Brian.
_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Macro recording capabilities

Fabio Zadrozny
On Wed, Jan 18, 2017 at 3:57 PM, Brian de Alwis <[hidden email]> 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​


_______________________________________________
platform-ui-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
Loading...