Community
Participate
Working Groups
The summary says it all but as an example please check Textpad's macros functionality.
not for 2.0
Reopening for 2.1 consideration
Macros should also have some more enhanced functionality to create custom macros like "fill line with char '*' starting from current cursor position till column 80".
Adding my 'vote' for macros. Like the original poster I'm also a fan of TextPad (www.textpad.com). I don't need to do anything too fancy with it - here's an example where I had to switch out of Eclipse and do something in TextPad and save it because Eclipse didn't provide macros: I had a bunch of lines of the form: Some text@more text@more text@more text and I wanted to change the @'s to newlines. So in TextPad I did: <control-shift-R (start macro)><control-F (find)>@<return (to close the find window and highlight the next @ sign)><return (to change the selected @ to a newline)><control-shift-R (end macro)> Then I could place the cursor on the first line and do <control-R><control- R><control-R>... repeatedly to change all the @'s. Actually since I had 10,000 of those lines what I did was use the macro repeat menu item to repeat the macro to the end of the file. There's also an option to repeat a certain number of times or until the end of the selection or line. There's probably a betr teway to perform this particular example but that's not the point, it's just an example to show the kind of simple operations that are made easier with macros. Some macro facilities allow you to edit the macro definitions, some going as far as letting you debug and single step them, but I can't speak for the other requesters but that is way overkill for what I want.
I just want to let the people on the cc list know that you can vote for bugs now and perhaps this bug deserves some votes!
Mhm. I thought the vote is automatically done by adding myself to the CC of this bug.
I don't think it is very easy to sort bugs according to how many people are in the cc list. However bugzilla has a voting mechanism which the eclipse team have currantly set to 10 votes per user per project.So adding yourself to the CC list may count as one vote but with the voting mechanism you can give a bug 10 votes if you wanted to.
If I remember correctly some Javascript scripting was present in version 1.0, but it took a back seet, disappearing completely in 2.0. It is time to add scripting/macro capability to the system. There is a lot of repetitive task that can be easily implemented by simple scripts. Currently this involves the difficult task of writing a plugin. It is time.
After seeing the power of macro magic in VI, I really want them in eclipse :-)
This bug appears to be a subset of bug 37936. Perhaps it should be marked as a duplicate.
*** Bug 40690 has been marked as a duplicate of this bug. ***
So is this bug gonna make it into 3.0? If I could put all my remaining votes into this bug, I would... too bad it only allows me to put 1 :(
>So is this bug gonna make it into 3.0? No.
Is this bug going to make it into 3.1?
Not yet decided. Also depends on how the platform's overall strategy for scripting will look like. Pls see the platform text plan.
I've written a simple scripting plugin that lets you write "macros" in whatever your favorite scripting language is (javascript by default), and assign those macros to keybindings and/or launch variables. However, there is no recording capability, so you need to be comfortable writing scripts that use the eclipse API in order to use it. It would be easy enough to include a dumbed down scripting API if anyone wants to contribute it. If you are interested, you can get it at: http://sourceforge.net/projects/sunshade http://sunshade.sourceforge.net/update No documentation, except for what you find in the Preference pages =)
Emacs also has a powerful macro facility. It records keystrokes etc. via M-x start-kbd-macro, M-x end-kbd-macro, M-x call-last-kbd-macro bound to Ctrl-x ( Ctrl-x ) Ctrl-x e as well as a M-x name-last-kbd-macro and M-x insert-kbd-macro to insert a named macros' definition into an Emacs Lisp file, so you can save such macros across sessions. This also allows you to edit the macros or create others from it with slight variations. There is also a macedit package in Emacs for more advanced macro editing. There are more advanced features, including inserting prompting inside buffers. You can repeat executions n times or indefinitely (i.e. until a macro hits an error condition such as a failed search). Note that most such macros require search/replace and other edit operations that execute without dialogs/prompting. I think that these are the important features of a keyboard macro facility.
(In reply to comment #17) > Emacs also has a powerful macro facility. This is actually one of the most important features of Emacs that continues to make it superior to Eclipse for mass-editing source files that exhibit a consistent pattern of code snippets, where a template has been copied and then a search and replace has been done to achieve the result. I regularly use a 'grep -l' to load matching source files into emacs buffers, record a repeatable set of many complex edits on the first buffer, and then use the Ctrl-U key many times to repeat the macro across each buffer. A similar technique is frequently necessary, when populating static data structures using output that is generated from a tool (e.g., grep or sed). After redirecting textual output and capturing it in the editor, one record per line, it needs to be reformatted with declarations, braces, quotes, and commas for the static initialization of variables in a Java source file. Emacs keyboard macros have proven themselves to be indispensible for these types of mass edits.
(In reply to comment #18) Ben, I totally agree that it one of the "must have" features. However in a mean time that most of this can be done using search and replace with regexps. Not that natural and simple as macro recording but with some practice you can do it quite quick. :-) In addition to that you can use global macro recorder. I'm pretty sure there is several utilities for Windows allows to do that.
*** Bug 104734 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > Is this bug going to make it into 3.1? Is this bug going to make it into 3.2?
no
This would be very useful for those developers who hate to do boring tasks or tasks that occur frequently
(In reply to comment #22) > no With all due respect, this continues to baffle me. I fail to understand why Eclipse can progress as far as version 3.2, while having been developed on for years by a huge group of developers, a good deal of which are paid by their companies to do a lot of high-quality work -- and yet still miss features that have a) proven themselves valuable, and b) been in competing products for decades (note the plural form). This feature has been requested since 2002. It currently has 60 votes. It is possible to implement it, other editors do. What exactly is it that prevents it from being implemented? Is it simply deemed "too advanced" or what is it? Sorry about the slightly grumpy tone, but this is one of the really significant things that keeps me from switching over entirely. Right now I'll fire up Emacs, again, in order to edit a file with a couple hundred lines that need to be massaged. I just cannot do it automatically within Eclipse. That, my friends, is sad. Regards.
As nice as eclipse is, I have to stop using it sometimes because of the lack of this feature. It is a feature that, even with the lack of other niceties in emacs, keeps me going back. I think the eclipse team is underestimating the power of defining and saving your own custom operations. If you don't use them extensively you really do not know what you are missing and is the #1 missing feature of eclipse in my book. Please give this some consideration. Thanks.
I just downloaded Eclipse yesterday and have been really pleased with what I've seen... until I just tried to find out how to record editor macros and discovered to my amazement that it is not possible. As a Vim (and every once in a while Emacs) user, it never even occurred to me that an editor intended for use by programmers would not provide this basic feature. Wow. Seeing that this bug has been around for 4 years and there is no evidence this will be fixed, this is very frustrating.
There is a new project in the Dash incubator called Monkey. This is the starting point for providing macros in Eclipse. It is functional and it is exactly what we are all asking. I recomend everybody to install Monkey and start playing with it. Here is the link: http://www.eclipse.org/dash/monkey-help.php?key=installing
I apologize if I am missing something, but how is Monkey an appropriate solution for keyboard macros? From what I saw, it's simply a scripting tool, which is not the same thing as a keyboard macro utility. Am I missing something, or is Monkey completely missing the point? See VIM, Emacs, or Visual Studio for examples of programmers editors that have great keyboard macro capabilities.
(In reply to comment #27) > There is a new project in the Dash incubator called Monkey. This is the > starting point for providing macros in Eclipse. It is functional and it is > exactly what we are all asking. Monkey is for scripting Eclipse. This is done by implementing DOMs you can use in your scripts. Monkey does not provide the capability of recording and playing keystrokes.
I saw a quick first hand view of the Eclipse Monkey at eclipsecon, and it's definately a step in the right direction. This tool will do maybe 60% to 70% of my needs for macros hands-down. Although I would like a rich UI interface that allows me to record macros, I would also like the scripting ability in the background to modify these macros. I miss my old WordPerfect macros too. What? WP too old for you? then why are you still using VIM/Emacs? It would be useless for me to have a VIM like macro facility that doesn't support re-usability in the RCP for other applications using the RCP. Think of UDIG using macros recorded by users for example. Since Eclipse does such a great job at being the best extensible IDE there is, and I do strongly believe it is the best, it needs to finish off it's feature's list with proper scripting. Eclipse Monkey is the way to go, but the solution does not end there for me, If anything, it tells me that I'm not the only one that think Eclipse is good with or without proper macro support, but can't wait until it is well integrated. I do not have cycles to contribute to this myself, but I'm wondering why VIM/EMacs users that know what they want out of the feature don't contribute to Monkey to make it evolve to their needs and wills?
I voted for this enhancement over two years ago. I can't believe that something this useful and prevalent in other IDEs is STILL not available in Eclipse. It's time to make some positive progress on resolving this issue. We need Keystroke macro recording/playback, as well as, a scripting capability such as Eclipse Monkey.
I'm surprised too. That for all the people voting for this, and complaining about it, that no one has come forward and offered to help fix. <grin> Just kidding! I know its complex and implications "peppered" throughout eclipse. That said, I think a lot of the recent work on "commands" is a step in the direction of allowing this, and its probably just not obvious that there has been movement towards it. Of course, don't let my remarks discourage anyone from volunteering ... but, offhand, I suspect it would take a commitmant of "full time" effort for 6 months or so. (Though, I really have no idea, just commenting).
So is this bug going (In reply to comment #21) > (In reply to comment #14) > > Is this bug going to make it into 3.1? > > Is this bug going to make it into 3.2? Is this bug going to make it into 3.3?
(In reply to comment #24) > (In reply to comment #22) > > no > > With all due respect, this continues to baffle me. I fail to understand why > Eclipse can progress as far as version 3.2, while having been developed on for > years by a huge group of developers, a good deal of which are paid by their > companies to do a lot of high-quality work Well, maybe that's the answer. Nobody's paying anyone to do macro recording capability :) > This feature has been requested since 2002. It currently has 60 votes. It is > possible to implement it, other editors do. What exactly is it that prevents it > from being implemented? Is it simply deemed "too advanced" or what is it? Yes, please--it would be good to have an answer from an Eclipse developer for this question. > Sorry about the slightly grumpy tone, but this is one of the really significant > things that keeps me from switching over entirely. Right now I'll fire up > Emacs, again, in order to edit a file with a couple hundred lines that need to > be massaged. I just cannot do it automatically within Eclipse. That, my > friends, is sad. I have switched to Eclipse. Except when I need to design a Swing GUI, I go to Netbeans. Or when I need to record+play macros repeatedly. I go to Ultra Edit. > > Regards. >
Here is the way I would see it working out: A major player like Borland listens to our pleeds. They submit the required modifications in Eclipse to support a macro utility that they include only in there integration of Eclipse as a version of JBuilder (or someone else with another product, but you get the point). Once the feature is built, you will have many people stating how XXX (lets say JBuilder) is much better than base Eclipse because it has recordable macros. Some (lets say 20% as a random number) of the community will be ready to pay for an even better Eclipse that leverages everything they have already. IBM will notice and will start a new sub-project to have this included into eclipse. Company Y( lets say Borland) will come in and donate the code because they don't want somoene else comming and making their stuff out of date. If any company is looking for a feature that will increase productivity on top of Eclipse for their added value product, this is it for me.
We're not yet in the planning phase for 3.3 but no doubt we'd put it on the plan if someone volounteered to contribute this feature.
I've been asked to comment on this bug. I'd tried to be brief, but failed. 0.) See Bug 35949 for a related bug. 1.) Familiarize yourself with regular expressions and use the Find/Replace dialog. I admit that this is not as powerful as macro recording and playback, but some of the examples listed here say "in a single file". If this is the case, then regular expressions are your friend. 2.) Eclipse Monkey will probably never be an acceptable replacement for macro recording and playback. It is a scripting language. While on the surface macros and scripts seem related, there is a key distinction. In one, you need to know the APIs used to trigger something. The other interacts with the user interface on the level of raw user events. 3.) To be fair, VI and Emacs (and even TextPad and others) are largely keyboard-based applications with minimal sophisticated features. What happens if someone presses "Alt+Shift+R" as part of a macro? I think part of the issue here is the complexity of the Eclipse user interface. (a) If the macro played back the keys too quickly, then a dialog that is in the process of opening would not receive the keys. (b) If the layout of the user interface changes, the macro might break. (c) What happens if a progress dialog opens while playing back the macro? (d) Do we support mouse input as well? 4.) This has interesting links to undo/redo operations and commands. But it's not clear what that relationship would be.
The relationship between key event recording and scripting is based on experience from Microsoft Windows based applications that rely on Visual Basic for Applications (VBA). When you start macro recording, the application begins writing the VBA script. Each keystroke or mouse click that invokes an application function will write the command to the script. Invoking the macro means executing the VBA script that was written. Scripting can certainly be thought of as a related and foundational mechanism that could eventually enable recorded macros from a GUI perspective with (much) additional work.
Ditto on #38. For example if you record a find command, it should boil down to a script line like: Find("aaa"); and not: PressKey("Ctrl+F"); FocusOnField(1); // what to search for EnterText("aaa"); ClickOnButton(17); // the ok button When the user clicks on the "OK" button, a "Command" in the GOF sense should be created and filled in with the text to find and options. That "Command" should be executable, addable to the Undo list, or serializable in a script (i.e., the Find() call above). Instead of reinventing the wheel here, is there an established way of doing this, like VBA or some other popular tool, that we could just copy and adapt?
I think a good model to follow for this feature is SlickEdit. It works very nicely and I don't think anyone who has used it would argue here. And no one can say that SlickEdit does not have a complex UI either so this should not be an issue as stated in comment #37. I think it really comes down to what is said in comment #35. The big players really have control here. There could be 10,000 votes for this bug, but if the votes don't come from the right companies it will never be implemented.
(In reply to comment #40) > I think a good model to follow for this feature is SlickEdit. It works very > nicely and I don't think anyone who has used it would argue here. And no one > can say that SlickEdit does not have a complex UI either so this should not be > an issue as stated in comment #37. You are mixing things up here. A complex UI does not automatically imply that a product also comes with a rich implementation. The point of comment 37 is that the Eclipse committers did think about this in the past are are still thinking about it. However, as Douglas pointed out, they are not going to implement it the dirty way by just recording key strokes and mouse clicks and replaying them. This wont work in Eclipse.
"...they are not going to implement it the dirty way by just recording key strokes and mouse clicks and replaying them. This wont work in Eclipse." And it doesn't work like this in other tools either. So I don't see your point. I respect trying to implement the right way, but I think what people are getting frustrated about is this enhancement is over 4 years old, has 65 votes, and still there is no plan for implementation.
I think comments 17 and 18 taken together pretty much voice my opinion. I do this stuff all the time with emacs and would love to have the ability to do it in eclipse. If it makes a difference to anyone, IntelliJ's Idea had it at least 2 or 3 years ago.
Hi. I would like to offer this project as an experiment (or proof of concept) in recording editor macros in Eclipse. https://macroshmacro.dev.java.net/ It uses ANT to play the macros. (Monkey may be a better choice) It registers to receive KeyDown and KeyUp events and registers an IExecutionListener to be notified when a command is executed. The ANT file uses Display.postEvent to post the keyboard events.
The "MacroShmacro" (cool name) plug-in works under 3.2 but it only handles simple typing in text files. If you do a Ctrl-F for example to do a find dialog, nothing you do in that dialog is captured. Even incremental find (Ctrl-J) is not captured. The way this should probably work is that typing a string, deleting a character, doing a find with certain options, creating a project, etc., those should all be some kind of Command, and the macro recorder should be able to record and play back those Commands. There is some support for playing Commands in the UA framework.
I apologize for posting this comment on this bug – it is a little off subject. I will post of an Eclipse newslist in the future. I just wanted to mention that the 3.2 version of macro-shmacro has been updated. It should record any keystrokes and commands generated from keystrokes. For example, it will record a ‘copy’ for a CTRL+C. However, it will *not* record a copy if the menu is used. It will *not* record any ‘find’ or ‘find/replace’ commands. There is a ‘findtext’ tag that can be added to the macro after recording. (The macro tag also has are ‘repeat’ attribute.) I looked at the way the find/replace dialog works and I could *not* find any way to “hook-in” to it. Anyway… I will continue this at a more appropriate location.
With regard to #37, I would like to say, "don't try for perfect when anything at all will be better than nothing" Specifically, > What happens if someone presses "Alt+Shift+R" as part of a macro? the macro aborts. > (a) If the macro played back the keys too quickly, then a dialog that is > in the process of opening would not receive the keys. > (b) If the layout of the user interface changes, the macro might break. > (c) What happens if a progress dialog opens while playing back the macro? > (d) Do we support mouse input as well? so, abort in these conditions. The user can figure it out. not perfect - but I know many java programmers who won't migrate to eclipse until it supports this basic feature... (and I tried shmacro and it got even the most basic things scrambled)
*** Bug 57105 has been marked as a duplicate of this bug. ***
*** Bug 120307 has been marked as a duplicate of this bug. ***
Just added my vote to have this implemented. I would like to say I agree with the sentiment that partial functionality in regards to this feature is not only acceptable, but is actually desirable as far as a first release is concerned. I find this feature to be very productive and is the sole reason I choose not to move to Eclipse as yet. Bediako George
I come from an environment (Code/400) that lets me interact with Lpex at a pretty detailed level and I really miss that in Eclipse. Just adding my vote to say that I strongly support the addition of a macro function to Eclipse.
*** Bug 35949 has been marked as a duplicate of this bug. ***
Adding my name to this bug since it is the most visible of the set of scripting-and-macro-related bugs. My original comment is in bug 37936 comment 19, where I listed related bugs that were open at the time. This was once even a plan item, in bug 80140, that was moved to the dreaded RESOLVED-LATER state after 3.1. Here is an updated list of open bugs for this issue: bug 8519 - **opened in January 2002, 5+ years ago** - 52 cc's, 104 votes bug 37680 - 21 cc's, 7 votes bug 37936 - 27 cc's, 22 votes
I've put something together in the Shmacro vein that is command-based. It is not a complete solution as it is limited by lack of native Eclipse support for macro concepts, but may be adequate for many users. https://sourceforge.net/project/showfiles.php?group_id=242831&package_id=296347&release_id=635310
(In reply to comment #54) > I've put something together in the Shmacro vein that is command-based. It is > not a complete solution as it is limited by lack of native Eclipse support for > macro concepts, but may be adequate for many users. That's all the experiment with bug 234710 will be, simply an option to capture key strokes and commands (if the command eats the keystroke). If it proves to be useful (and non-threatening :-) we could possibly add the enabling enhancements to WorkbenchKeyboard in 3.5. PW
(In reply to comment #55) > (In reply to comment #54) > > I've put something together in the Shmacro vein that is command-based. It is > > not a complete solution as it is limited by lack of native Eclipse support for > > macro concepts, but may be adequate for many users. > > That's all the experiment with bug 234710 will be, simply an option to capture > key strokes and commands (if the command eats the keystroke). If it proves to > be useful (and non-threatening :-) we could possibly add the enabling > enhancements to WorkbenchKeyboard in 3.5. > > PW > That would be good. What I put together lets you edit/delete/share macro definitions and lets advanced users do some BeanShell scripting. Will 234710 cover any of that?
Still no solution now 12 years later?
New Gerrit change created: https://git.eclipse.org/r/50151 WARNING: this patchset contains 2281 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Gerrit change https://git.eclipse.org/r/50151 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=1fcd2c69ed8ce3e0c114b27051d209d80863b695
I've submitted a first cut to provide keyboard macros to the e4 incubator. You can install it by using Help > Install New Software from http://download.eclipse.org/e4/snapshots/org.eclipse.e4.ui/ under the Macros section. The implementation is specific to the Eclipse 4.x stream and has only been tested with 4.5 (Mars). There's some documentation at: https://wiki.eclipse.org/E4/Macros
(In reply to Greg A Seguin from comment #35) > Here is the way I would see it working out: > > A major player like Borland listens to our pleeds. They submit the required > modifications in Eclipse to support a macro utility that they include only > in there integration of Eclipse as a version of JBuilder (or someone else > with another product, but you get the point). > > Once the feature is built, you will have many people stating how XXX (lets > say JBuilder) is much better than base Eclipse because it has recordable > macros. Some (lets say 20% as a random number) of the community will be > ready to pay for an even better Eclipse that leverages everything they have > already. IBM will notice and will start a new sub-project to have this > included into eclipse. Company Y( lets say Borland) will come in and donate > the code because they don't want somoene else comming and making their stuff > out of date. > > If any company is looking for a feature that will increase productivity on > top of Eclipse for their added value product, this is it for me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have been following this request and simmilar request across the market place and was really surprised that there was no priority assigned to the request as there was no clear guidance..i do agree that recording macros is one of the most popular request in eclipse from qa.. Integrating eclipse with the other jars is only distorting the amazing tool capabilities.
(Sorry if this comes in the middle of a discussion) FYI, SWTBot managed to implement some recording/playback capabilities. See https://wiki.eclipse.org/SWTBot/Generator for reference.
New Gerrit change created: https://git.eclipse.org/r/89953
New Gerrit change created: https://git.eclipse.org/r/89956
The 2 Gerrit changes I've just submitted (one for eclipse.platform.ui and another for eclipse.platform.text) should provide the structure for macro record/playback. The current implemented features include: - Action for toggle record (added to toolbar) - Action for playback (added to toolbar) - Record/playback of whitelisted commands recorded in the KeyBindingDispatcher - Record/playback of keystrokes in the text editor - Allows other plugins to participate in the record/playback as needed - Persist/Load the last recorded macro to/from disk Future work (not included right now to prevent the current patch from becoming too big -- and the current patch already covers many use-cases): - Make more actions aware of the macro record mode (for instance, the find action must be macro aware so that it can be played back accordingly, so, for now it's not whitelisted -- likewise for code-completion). - Provide a way to persist macros under a given name. - Provide a way to replay a macro X times (or until the end of the file is reached). - Provide a way to edit a saved macro. I'll create proper bug reports for these once the current patches get properly reviewed/integrated.
Gerrit change https://git.eclipse.org/r/110584 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=7756012c5f6ca2ad420e5a959f27f2e94378841a
New Gerrit change created: https://git.eclipse.org/r/110932
Gerrit change https://git.eclipse.org/r/110932 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=37ed87bc099774266fe181ef7f670a7944e93734
As a note, I've restarted work on this task. I've finally been able to put what I had in the incubation. Also, updated the wiki (https://wiki.eclipse.org/E4/Macros) to point to info regarding it. Right now it should be usable already and my plan is being able to integrate it into the 4.8 stream, so, I'd like to collect feedback (into this bug right now) about what's currently available in the incubation. p.s.: Note that it's not feature-complete already, but my plan is making sure that the record/playback is *very* solid before adding more functionality, so, feedback is appreciated -- note that the implementation targets what's available in all other editors (so, it's record/playback in the scope of the editor, not a general macro record/playback to script the whole ide -- that's the focus of Bug 37936 and is not what I'm tackling).
*** Bug 234710 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/115322
Gerrit change https://git.eclipse.org/r/115322 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=685be0d56c197750a0a227af1c8d66dd27fe72be
New Gerrit change created: https://git.eclipse.org/r/115347
Gerrit change https://git.eclipse.org/r/115347 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=ccbcbf6716145709aeeb3f48eace401f78542b27
New Gerrit change created: https://git.eclipse.org/r/117885
Gerrit change https://git.eclipse.org/r/117885 was merged to [master]. Commit: http://git.eclipse.org/c/e4/org.eclipse.e4.ui.git/commit/?id=8dbc29aa4279e9c3de75001bbeb1ee820ea54320
