Community
Participate
Working Groups
Recording commands and text keystrokes might go a long way to providing macro recording. This requires some investigation.
Created attachment 102722 [details] Macro project archive v01
This experiment seems to have a lot in common with https://bugs.eclipse.org/bugs/show_bug.cgi?id=8519#c44 PW
The latest version of the investigation is now in e4-incubator/ui/org.eclipse.e4.text.macro It's not very predictable, although it should be. PW
(In reply to comment #3) > The latest version of the investigation is now in > e4-incubator/ui/org.eclipse.e4.text.macro > > It's not very predictable, although it should be. It turns out that bug 247069 was killing me on linux. PW
I can't seem to find the incubator website, so I apologize if the following is already taken into account. I think it would be more useful to start with turning all actions into commands. This can be used as a base for further macro support. In my macro recording work, I started with the idea of capturing commands. I turned any keystrokes that were entered into commands if possible. So I: 1. created new commands that are currently missing from the system. Ex. Move cursor up (i.e. up arrow). There is no command for this, but the StyledText widget knows how to process the keystroke. I added new commands for all of the ST command constants. 2. I translated character keystrokes into commands. So if I decided they typed 'A', then I created an instance of command InsertString("A"). One problem that I didn't have a solution for was special modes. I expect intellisense to generate commands for inserting a string, not necessarily to record the invocation of intellisense and moving the cursor in the hover tip and hitting return. I think users are smart enough to know that you can't really record that. However, there are other modes (like matching quote mode) that could really benefit the command recording by issuing commands instead of doing operations directly on the document. In my experimentation, in a Java document, typing '"' was handled by a VerifyKeyListener on the Editor. That listener inserted the matching quote directly into the document; the StyledText object didn't even receive an event, you'd have to listen to the document listener. This made it very difficult to figure out which events should be recorded from which listener. I believe the solution is to encode those inserts as commands instead, channeling the changes through one interface. So I would see something like: InsertString("\"\"") //inserting the quote and matching quote Move Cursor Left //putting the cursor back between the quotes Move Cursor Right //the user typed over the quote, leading to no document change This requires that editor operation be made macro-enabled I think, since only they have semantic knowledge of the edits they are performing. A playback should work the same way regardless of whether a user has "insert matching quotes" mode turned on or off.
(In reply to comment #5) > I can't seem to find the incubator website, so I apologize if the following is > already taken into account. > > I think it would be more useful to start with turning all actions into > commands. This can be used as a base for further macro support. In my macro > recording work, I started with the idea of capturing commands. The direction of this experiment is to capture any commands that are issued or keystrokes that aren't filtered by the WorkbenchKeyboard. The commands can be replayed through the IHandlerService, and the keystrokes by simply using org.eclipse.swt.widgets.Display.post(Event). The "everything is a command" macro/scripting support has to be in there from the ground up, and will be looked at in e4. However, simply being able to re-post commands and key strokes might go a long way to help in 3.x. AFAICT this won't allow scripting of eclipse in the broad sense, but would allow text macros to be created within an editor and then executed. PW
Okay, that sounds reasonable. I am not expecting that this would allow for general scripting of Eclipse. I think that is a different problem with different requirements. However, I did have one question. I think in my experiments that mixing Display.post() with command execution gave me some issues with out of order execution. It seemed to work if I posted the command executions as well, but I was still uncomfortable with it.
(In reply to comment #3) > The latest version of the investigation is now in > e4-incubator/ui/org.eclipse.e4.text.macro The CVS Repo for this path is :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse and then look in HEAD PW
(In reply to comment #7) > However, I did have one question. I think in my experiments that mixing > Display.post() with command execution gave me some issues with out of order > execution. It seemed to work if I posted the command executions as well, but I > was still uncomfortable with it. I've updated the project to use WorkbenchKeyboard directly (the tweaklet patch must be applied to org.eclipse.ui.workbench, and is in /org.eclipse.e4.text.macro/org.eclipse.ui.workbench.txt) This version will record one macro and can replay it. It has the above mentioned problem that all the commands get executed while the posts start to trickle in because they're posted from another thread. Also, it will only replay lower case :-) Steve had mentioned that you didn't have to post the events from a different thread (although that's what at least one of their snippets does). I'll investigate further. PW
Closing this issue. I've submitted an initial implementation regarding text macro recording in Bug 8519 -- the artifacts from that can be already installed in Eclipse through the incubation snapshots -- https://wiki.eclipse.org/E4/Macros has more info (waiting for more feedback on Bug 8519). *** This bug has been marked as a duplicate of bug 8519 ***
