Community
Participate
Working Groups
Editor should have option for copying whole line under cursor when pressing Ctrl-INSERT | Ctrl-C without any text selection.
Are there any other editors supporting this kind of feature? If anything, I think it should be a different accelerator.
At least Visual SlickEdit supports this feature. Moreover, it supports cut (SHIFT-DEL) of current line. I agree with your, it may be different accelerators. But I think, that it will be good, if your will add settings to standard copy/cut to perform such 'whole line' actions.
*** Bug 73526 has been marked as a duplicate of this bug. ***
*** Bug 80347 has been marked as a duplicate of this bug. ***
Do you plan to add it to Eclipse 3.1?
Setting target to 3.1 (time permitting).
*** Bug 96561 has been marked as a duplicate of this bug. ***
in reply to the question in comment #1: idea / intelliJ supports this as well
Please, please? As a long-time Slickedit user, I am having a hard time living without copy-line if nothing selected. If anyone can point me to a plug-in that provides this functionality, I'd appreciate that in the mean-time.
IntelliJ IDEA can do that.
*** Bug 201297 has been marked as a duplicate of this bug. ***
Let's do this for 3.4.
You can use Ctrl+Alt+Up/Down to copy a line and then either use Ctrl+X to cut it or Ctrl+Up/Down to move it where you need it. Hacking the normal copy to copy the whole line if the selection is empty is a no go as this would be unexpected behavior.
This is no unexpected behavior if you would have used IntelliJ IDEA. Maybe you should reread the initial posting: Andrew does not suggest to change the default, but to have an option to make Ctrl-C copy the whole line, Ctrl-X cut the whole line when nothing is selected. As you may know from a lot of editors Ctrl-Y delete the current line, so why not extend it to delete the selection if any?
It's also not unexpected behavior for people who use Visual Slickedit, or other top-notch editors. Eclipse does have plenty of other functions which do different things based on if there is a current selection or not, so this would be a natural fit. Select line is a common thing... and when I have to do home to get to the beginning of the line, shift-down to select line, then copy, it's relatively cumbersome. The worst part is that often (since I expect this behavior) I will do my copy assuming the line was copied, go elsewhere in the code, and paste, and it pastes something from the past... there's no indication that the copy (without a selection) was a no-op.
Keep in mind that we are not just an IDE. While your suggested behavior is true for some developer editors it is not present in any normal application that lets you edit text. Another problem is that some Eclipse editors can have/contribute their own copy action in which case a general setting would not be honored. What about separate 'Copy/Cut Line' commands? The disadvantage with that is that you need to learn a separate command (e.g. Ctrl+Shift+C/X).
> What about separate 'Copy/Cut Line' commands? The disadvantage with that is > that you need to learn a separate command (e.g. Ctrl+Shift+C/X). No command for just copying/cutting the line (but not copying when something is selected), but maybe separate commands which copy/cut the selection or - if nothing selected - the whole line. Then it is enough for us to change the keybinding and that's it. No GUI option would be necessary.
i prefer ctrl+c/v/x to use for copy/cut whole line if nothing is selected. why learn a new key for this? ctrl+c/v/x is default for copy actions.
One resolution would be to make copy/cut whole line if no selection a preference. It would be disabled by default to avoid breaking backward compatibility but a user could enable it.
The problem is that all editors with custom cut/copy/paste code need to be updated plus the default widget cut/copy/paste overridden.
Note that the request in bug 253165 conflicts with this. If at all, we should consider which is more valuable (I tend to think the other behavior is nicer).
(In reply to comment #21) > Note that the request in bug 253165 conflicts with this. If at all, we should > consider which is more valuable (I tend to think the other behavior is nicer). of course that is, copy whole line without any selection is nonsense as default behavior for ctrl+c/v/x. But copy, paste word without any selection if great feature, I know that because I worked with editor which support this excelent feature and I can tell that this feature accelerate development about 20-30%
of course that is, copy just word without any selection is nonsense as default behavior for ctrl+c/v/x. But copy, paste whole line without any selection is great feature, I know that because I work with an IDE which support this excellent feature and I can tell that this feature accelerate development about 30-40%
(In reply to comment #23) > of course that is, copy just word without any selection is nonsense as default > behavior for ctrl+c/v/x. > > But copy, paste whole line without any selection is great feature, I know that > because I work with an IDE which support this excellent feature and I can tell > that this feature accelerate development about 30-40% :D, can you tell me which editor provide copy, paste, cut whole line as default copy actions(so ctrl+c/v/x) ? I want to try it.
> :D, can you tell me which editor provide copy, paste, cut whole line as default > copy actions(so ctrl+c/v/x) ? I want to try it. Visual Slickedit, and IntelliJ IDEA are the two that I'm familiar with. I'd also like to say that this feature doesn't conflict with the ctrl-click to copy word bug/feature that someone compared it to. This one is keyboard driven, and the other mouse-driven, so you could do both. Slickedit also has a clipboard history, so you can paste anything you copied, not just the most recent. Slickedit also does context tagging much better than Eclipse. You can jump to definitions of anything and jump back instantly. It's really worth spending some time with.
*** Bug 371201 has been marked as a duplicate of this bug. ***
I requested a "select current line" editor command that by default would not be bound to a key, but users could bind if they chose to. It is supported by editplus which maps it to Ctrl-R by default. It stops short of giving many of the requestors what they ask for but it is better than nothing. If you want to copy the current line it becomes Ctrl-R-C, if you want to cut it, it becomes ctrl-R-X. My request was mapped to this request. Upon reading the thread, I think that each of the requests merits a "command" or "function" in the editor but none of the requests should be mapped to a key by default. Users should specically opt-in, either by binding the keys themselves, but more likely because we would write "plug-in" files for them that would map keys to the editors that we are used to. When installing eclipse, prominent documentation should let people know what familiar bindings are available and how to contribute bindings to emulate their favorite editor if it does not exist already. I thing we need: select current word select current line cut current word cut current line copy current word copy current line replace current word replace current line duplicate current word (may already exist) duplicate current line (already exists) delete current word (may alreay exist) delete current line (may already exist) A difference that I have with some of the requstors is that I believe these actions, if bound should work without respect to a current selection or lack of a current selection. We also need to define where the cursor ends up after the operation is completed. For the select current word/line I suggested the begining of the selection. For duplicate current word/line I recommend at the end of the duplicate. I have not thought through the rest of them yet. I repeat that none of these should be given default key bindings, but I also don't think we should question people that have asked for them. In every case, they would not have taken the time to write if they did not find them to be a time saving and appreciated feature of the environment that they are coming from. Thats good enough for me. I don't consider any of these difficult to implement, given all the pre-existing code. Every thing already exists, the components just need to be abstracted and then coupled in the way people have asked. I will volunteer to do it if someone that knows the internals can point me to the existing code.
(In reply to comment #28) Please let's keep this bug for the concrete request. If you want to start working on this, first read: http://wiki.eclipse.org/JDT_UI/How_to_Contribute which explains how to contribute to JDT UI, but it's essentially the same for Platform Text. Then take a look in the 'org.eclipse.ui.workbench.texteditor' plug-in how 'command.cutLine.name' is implemented and do the same for 'command.copyLine.name'.
I support this proposal. > Hacking the normal copy to copy the whole line if the selection is empty is a no go as this would be unexpected behavior That's now 2 very popular IDEs having this feature, and users seem to like it. So it's now not so unexpected, and even if unexepected it doesn't mean it's undesirable (after all any creation is unexpected until it exists). The current Ctrl+C with empty selection does nothing. But usually, someone doing Ctrl+C expects to do *something* (otherwise why hitting Ctrl+C?). So the proposed something is more likely to bring satisfaction than the current nothing.
(In reply to Mickael Istria from comment #30) > I support this proposal. > > > Hacking the normal copy to copy the whole line if the selection is empty is a no go as this would be unexpected behavior > > That's now 2 very popular IDEs having this feature, and users seem to like > it. So it's now not so unexpected, and even if unexepected it doesn't mean > it's undesirable (after all any creation is unexpected until it exists). > > The current Ctrl+C with empty selection does nothing. But usually, someone > doing Ctrl+C expects to do *something* (otherwise why hitting Ctrl+C?). So > the proposed something is more likely to bring satisfaction than the current > nothing. I no longer have any objection. We can add an option if users will complain about the new behavior.
Hello, I have a few questions: 1) Where exactly should I be looking to add the code for this feature? Karsten Thoms mentioned have a look at org.eclipse.ui.actions.TextActionHandler.CopyActionHandler. Is that the correct location? 2) Is there a way to print my copy action to logs? Currently I have placed a few println statements in the org.eclipse.ui.actions.TextActionHandler.CopyActionHandler methods. They do print but only when the application is starting up. When I copy something in the new IDE, nothing prints on current IDE. I was expecting it to be continuous listening action. Whenever I copy something, my println statements should print. But they don't (only at the beginning of application startup do they print). 3) Dani Megert mentioned: > Then take a look in the 'org.eclipse.ui.workbench.texteditor' plug-in how > 'command.cutLine.name' is implemented and do the same for > 'command.copyLine.name'. For this, I setup new workspace (all thru Oomph). And I was able to run it without any problems but nothing prints on console. Nothing. Can someone please help me with this? Thanks.
org.eclipse.ui.actions.TextActionHandler.CopyActionHandler extends org.eclipse.jface.action.Action Inside Action class, there is a runWithEvent method that is overridden in CopyActionHandler. So I placed print statements in Action class, and whenever I copy any selection, it always prints my line... There is some progress...
ctrl + c on a line of text in a java editor comes down to this place: org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.run() Got it this far at least.
(In reply to Faraz Durrani from comment #34) > ctrl + c on a line of text in a java editor comes down to this place: > org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.run() > Got it this far at least. Note that if you change this in JDT code, the change will only affect the code of the Java editor and will not change the behavior of other editors (plain text, XML, and so on). I don't think we can accept in the IDE a behavior for Ctrl+C on empty selections that differs from an editor to another, so the solution needs to be generic. See also the enablement of the Copy command. Copy command (and menus) is by default disabled for empty text selections, which means that just changing the command wouldn't be enough, but you'd also need to modify the enablement of the command. At this point, it seems simpler to just try adding an extra handler to the org.eclipse.ui.edit.copy command, which would only be activated in case current selection is an empty text selection, and that would take care of filling the clipboard.
Mickael Istria for the pointers. > See also the enablement of the Copy command. Copy command (and menus) is by > default disabled for empty text selections, which means that just changing the > command wouldn't be enough, but you'd also need to modify the enablement of the > command. Yes I noticed this just now. > org.eclipse.e4.ui.bindings.keys.KeyDownFilter.handleEvent > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press > org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand > org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler > org.eclipse.core.commands.ParameterizedCommand.executeWithChecks > org.eclipse.core.commands.Command.executeWithChecks It stops in Command class inside executeWithChecks method. But if there is a selection, it proceed further to > org.eclipse.jface.action.Action.runWithEvent > org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.run > org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.internalDoOperation > org.eclipse.jdt.internal.ui.javaeditor.ClipboardOperationAction.doCutCopyWithImportsOperation etc. > At this point, it seems simpler to just try adding an extra handler to the > org.eclipse.ui.edit.copy command, which would only be activated in case > current selection is an empty text selection, and that would take care of > filling the clipboard. 1) Where do I do this? 2) Is there a similar class which I can refer to? 3) That will also take care of filling the clipboard? 4) Would this also make it generic across plain text, XML, etc? I really appreciate your help.
(In reply to Faraz Durrani from comment #36) > 1) Where do I do this? http://help.eclipse.org/photon/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fworkbench_cmd_handlers.htm tells more about it. > 2) Is there a similar class which I can refer to? You can look at the various implementations of org.eclipse.core.commands.AbstractHandler class. Take the ones that do a simple small task as example. > 3) That will also take care of filling the clipboard? That will be up to you to implement this ;) But I think it's the desired behavior. > 4) Would this also make it generic across plain text, XML, etc? If you define a good enablement condition (whenever current selection is an empty TextSelection) and use plain Platorm API, yes, it should work on all Text Editors (and maybe even on all StyledText and Text widgets)
Your fishing in the wrong lake ;-) Take a look #canDoOperation and #doOperation in TextViewer and ProjectionViewer. HTH.
(In reply to Mickael Istria from comment #37) Thank you very much for this. Let me under Handlers (AbstractHandler) first. Then I will come to next part. One step at a time.
(In reply to Dani Megert from comment #38) > Take a look #canDoOperation and #doOperation in TextViewer and > ProjectionViewer. Just to clarify: This will help you to see the full call stack when setting breakpoints there. BUT: You must not implement it there because the viewers can be used anywhere, not just in our textual editors.
(In reply to Mickael Istria from comment #37) > http://help.eclipse.org/photon/index.jsp?topic=%2Forg.eclipse.platform.doc. Hi, That is a informative link. I read about commands, handlers, and bindings. I understand that CTRL+C is bound to a command which in turn calls a handler. I couldn't find which plugin.xml has a ctrl+c binding. I found the command though. I also just couldn't find the handler. There is this code in org.eclipse.ui.internal.handlers.E4HandlerProxy.canExecute(IEclipseContext, IEvaluationContext, MApplication): @CanExecute public boolean canExecute(IEclipseContext context, @Optional IEvaluationContext staticContext, MApplication application) { if (handler instanceof IHandler2) { Object ctx = staticContext; if (ctx == null) { ctx = new ExpressionContext(application.getContext()); } **((IHandler2) handler).setEnabled(ctx);** } return handler.isEnabled(); } This line--**((IHandler2) handler).setEnabled(ctx);**-- is going to AbstractHandler class. I just couldn't find the subclass that handles it. The thing is, if there is a selection, that line of code does something in it and that sets enabled to true. And when there is no selection, it does something that sets (or keeps) enabled to false. I want to see which subclass handles it. I want to see what is going on in it. And I just couldn't figure out which class is it. I am gonna dig more tomorrow.
Back to square one. Starting from the beginning. Probably should have started from there in the first place. http://www.vogella.com/tutorials/EclipsePlugin/article.html#extending-the-eclipse-ide
