Community
Participate
Working Groups
Add column based editing: cut/copy/paste/move, etc. colums of text.
not for 2.0
IMO this is a general text editor feature request.
What to do when proportional fonts are used? Block selection is not possible in StyledText.
If the font was proportional, it would have to switch to a proportional one to allow block selection.
*** Bug 22582 has been marked as a duplicate of this bug. ***
The editor I got this idea from (EditPlus) uses a simple screen drawing technique for proportional fonts. All boundaries are defined by the characters in the top-most select row. The selection start at the first full character in the top row and ends after the last full character. On each subsequent row it selects the first full character with a horizontal poition => the top row start and similarly for the ending. Another method would be to select characters m to n in each row where m and n are defined by the top row range or m by the first selected row and n by the last selected row. Or, as you say, force proportional.
*** Bug 40076 has been marked as a duplicate of this bug. ***
*** Bug 33790 has been marked as a duplicate of this bug. ***
*** Bug 44269 has been marked as a duplicate of this bug. ***
*** Bug 45807 has been marked as a duplicate of this bug. ***
*** Bug 50850 has been marked as a duplicate of this bug. ***
Hi! I was going to post a new feature request, asking for column editing, but saw this bug, still open. Any plans to implement this feature, for the next releases? Thanx, Alvim.
not for 3.0
Not for v2.0, not for v3.0 ... the bookies in Vegas are giving even money on v7.1 Come on Daniel, we all know that you secretly really _want_ to implement this.
*** Bug 78289 has been marked as a duplicate of this bug. ***
*** Bug 82310 has been marked as a duplicate of this bug. ***
*** Bug 83812 has been marked as a duplicate of this bug. ***
*** Bug 89204 has been marked as a duplicate of this bug. ***
*** Bug 93443 has been marked as a duplicate of this bug. ***
*** Bug 32128 has been marked as a duplicate of this bug. ***
See also bug 32128, which calls the feature rectangular selection.
Any plans for 3.2?
*** Bug 115792 has been marked as a duplicate of this bug. ***
*** Bug 123756 has been marked as a duplicate of this bug. ***
I think Eclipse platform should support vertical column cuts and paste function. UltraEdit has it, EditPad has it, JBuilder has it, Visual Studio has it, but Eclipse has NOT. It's a long-waiting function. I used to had a plugin which can do this, but after update eclipse from 3.1 to 3.2, I lost this function, and I can not rember which plugin I use. After a lot of search on google, I gave up searching ant report it as a bug.
I believe you were using the Lunar-Eclipse plug-ins: http://sourceforge.net/projects/lunar-eclipse/
The summary should be changed from "Add column based editing capabilities to Java Editor" to "Add column based editing capabilities to Text Editors", because there are lot of editors wich will benefit from this.
I would prefer the support for vertical column cuts and paste function as in Visual Studio because it's very comfortable. Especially moving vertical selectioned text with the <Tab> key. I would also integrate this feature into all Text Editors. It always helps formatting text.
*** Bug 124503 has been marked as a duplicate of this bug. ***
FYI: http://sourceforge.net/projects/columns4eclipse
*** Bug 155519 has been marked as a duplicate of this bug. ***
*** Bug 157362 has been marked as a duplicate of this bug. ***
Adding my vote for this. We use the editor extensibility and have many requests from our customers to add this feature. Its a shame that the styled text widget cannot do this when so many other editors can.
Created attachment 57686 [details] org.eclipse.text.diff.txt Patch against HEAD of 20070129 of org.eclipse.jface.text, o.e.ui.workbench.texteditor, o.e.ui.editors and o.e.jdt.ui. This patch implements column mode in Eclipse text editors. It relies on the patches against SWT posted in bug 8521. It is not final but allows to work with column mode and test the functionality, and also serves to preview the API impact of the final patch. Features: - toggle column mode by pressing Alt+C or pushing the toolbar button (you may need to show the "Editor Presentation" toolbar to see it). - support for delete, insert, cut, copy paste etc. - automatic font switching if the normal editor font is proportional API impact: - org.eclipse.jface.text: - new interface IColumnTextSelection extends ITextSelection - with default implementation ColumnTextSelection extends TextSelection - org.eclipse.ui.workbench.texteditor: - new interface ITextEditorExtension5 adding column mode functionality - AbstractTextEditor to implement the new interface - new method AbstractTextEditor::enableColumnSelectionMode(boolean) that allows subclasses to selectively enable column mode (column mode is disabled by default in order to not break existing subclasses) - new constant AbstractTextEditor::COLUMN_MODE_FONT for the column mode font preference - new constants for the column mode action / command in - IAbstractTextEditorHelpContextIds.java - ITextEditorActionConstants.java - ITextEditorActionDefinitionIds.java - ITextEditorExtension5.java
Created attachment 57687 [details] column_mode_icons.zip Icons for the column mode toolbar button. The icons are a quick attempt and should merely serve as a placeholder / input for an icon designer. They should go into org.eclipse.ui.workbench.texteditor/icons/full.
Tom, I will look at this patch as soon as SWT officially commits to that for 3.3 and has a milestone assigned. Note that "Alt+ char" key bindings must not be used as they interfere with mnemonics.
*** Bug 180306 has been marked as a duplicate of this bug. ***
*** Bug 184300 has been marked as a duplicate of this bug. ***
Created attachment 65347 [details] column_mode.zip The attached zip file contains a workspace patch based on the previous patches for all affected plug-ins (swt, jface.text, ui.workbench.texteditor, ui.editors, jdt.ui) and also includes icons. The patch is against Eclipse 3.3M6. Also, I set up a micro-site providing the patched plug-ins of Eclipse 3.3M6 at http://tkilla.ch/column_mode, which should make it easy to try the patch out for any interested parties.
The patch is working fine with the JDT and Text editor but NOT with the C/C++ editor (CDT). It should work for any kind of textual based editors in eclipse! It's very nice, that drag 'n drop is almost working too but moving the the selected column within a line is not always working correctly!
Just added another vote and have a question - the block selecting feature in Code Write is done by use of the Right mouse button and it an excellent extension to the use of the mouse that I could think of. Is there any chance that we might see something similar for the Eclipse too? Thanks!!
The Plugin for M6 is working fine with Text editor! It would be great to use it with Eclipse 3.3 and CDT4.0 editor. Any plans to update this plugin for final Europa releases? Thanks!
(In reply to comment #42) > The Plugin for M6 is working fine with Text editor! It would be great to use it > with Eclipse 3.3 and CDT4.0 editor. Any plans to update this plugin for final > Europa releases? Obviously Europa has left the station. Daniel, what are your current plans for this feature? We have significant customer interest in it and would be willing to help however you need.
Hi Doug. Please note that this strongly depends on bug 8531 i.e. until SWT's StyledTextWidget provides support there's nothing I can do here.
Cool. Thanks, Daniel. I'll check out the SWT bug.
(In reply to comment #44) Typofix - the SWT bug in question is bug #8521.
*** Bug 23255 has been marked as a duplicate of this bug. ***
*** Bug 204570 has been marked as a duplicate of this bug. ***
any plans for a release of this feature? 3.4?
Looks like we're all waiting on bug #8521 to get fixed first, aren't we?
>Looks like we're all waiting on bug #8521 to get fixed first, aren't we? Yep.
*** Bug 235970 has been marked as a duplicate of this bug. ***
Comment on attachment 65347 [details] column_mode.zip I have updated the combined SWT/Text patch attached to the SWT bug (see bug 8521 comment 38) with an Eclipse 3.4 version, obsoleting this patch. For Eclipse 3.4 users, there is also an update site at http://tkilla.ch/column_mode which offers feature patches containing the patch.
Investigating...
Created attachment 118701 [details] block_selection.patch This patch against HEAD of 20081125 updates the previous 3.4 version of the patch using the new SWT APIs published in 3.5M3. It is quite incomplete feature-wise but enables playing with block selection. What's working: - block selection mode toggling using Alt+C (I know...) or the toolbar button (must be enabled via 'Customize Perspective > Editor Presentation'). - monospace font toggling when block mode is enabled - copy, paste, typing What's not working: - undo (works only one line at a time, I guess SWT sends out n events for n changed lines) - DND (commented out, I will have to look into this) - any modifications within the whitespace beyond the end of a line The following plug-ins are affected: - org.eclipse.jface.text - org.eclipse.ui.workbench.texteditor (note that the icons must be extracted from the previous obsolete zip) - org.eclipse.ui.editors - org.eclipse.jdt.ui
I've reviewed the patch and how it feels in the UI. So far I see no show stopper in the patch itself (detailed comments will follow in next comment). The only thing we need to get a feeling for is how much effort is needed to complete the patch feature-wise. Having said that I see stop ship issues in the resulting LAF that comes from StyledText: P1 bug 257237: cut/copy & paste not usable without virtual spaces P1 bug 257238: block selection mode: trouble with caret and newline P2 bug 257240: cross cursor is unexpected when in block selection mode P2 bug 257236: strange selection look P2 bug 250179: it's not obvious which characters are part of the selection
Some feedback to the patch itself (in random order): - supportsColumnSelection() ==> isSupportingColumnSelection() or isColumnSelectionAvailable() - however, I'm not sure we really need this: the action in the action set and in the ATE is there for all textual editors. What's the risk of offering if for all editors? I mean it's off by default anyway. - in the editor code don't use getTextWidget().getBlockSelection() but call isColumnMode() instead - some interfaces look strange/artificial to me (or at least needs better doc): org.eclipse.ui.texteditor.IDeleteLineTargetExtension.deleteLine(IDocument, ITextSelection, int, boolean) - Column Mode Font ==> Text (Editor) Column Mode Font - XXX should TextSelection open its document to subclasses? */ ==> I think it's OK to make it protected - access to widget in propertyChanged should be protected against being disposed - org.eclipse.jface.text.IColumnTextSelection.getRegions() and getText() look like helpers. Do we really need this in the interface? - org.eclipse.jface.text.SelectionProcessor: I'm declined to make this API. So far only two methods are used outside jface.text ==> we could put the must-have methods into JFaceTextUtil for now - replace outdated 3.3 occurrences with 3.5 - icons: I assume you also see those as placeholders that we will repalce with icons from the designers - tool bar: Toogle Column Sel... ==> 'Enable Column Mode' - we no longer use hoverIcon ==> remove from icons dir and from plugin.xml - as you already marked: some classes need Javadoc - help doc is needed
I've discussed the review feedback with Tom and we are on the same page. Currently we are still discussing some of the remaining SWT issues. This will have to wait for early M5.
Created attachment 121140 [details] block_selection.patch This is the current state of the work addressing the issues from comment #57. None of the other problems mentioned in my previous post (most notably undo support) have been addressed. > Some feedback to the patch itself (in random order): > - supportsColumnSelection() ==> isSupportingColumnSelection() or > isColumnSelectionAvailable() DONE. I have also replaced "column mode" or "column selection" by "block selection", which I believe is the name the feature runs under now. I think it is not required but helpful if SWT and the platform use the same terminology; also, the text editors already use the term 'column' for the rulers (IVerticalRulerColumn). > - however, I'm not sure we really need this: the action in the action set and > in the ATE is there for all textual editors. What's the risk of offering if > for all editors? I mean it's off by default anyway. Well, the risk is that some concrete editor may have some actions that implicitely expect a linear selection and do not work as expected with column selection. The actions wouldn't fail hard, its just that the user may not see the expected result and the plug-in owners may have to provide similar code to what we had to do in JavaEditor (none of these fixes was very bad, though). DONE: removed ITextEditorExtension::isBlockSelectionSupported. This also reduces the set of modified plug-ins, as there org.eclipse.ui.editors is no longer touched by the patch. > - in the editor code don't use getTextWidget().getBlockSelection() but call > isColumnMode() instead DONE. > - some interfaces look strange/artificial to me (or at least needs better doc): > org.eclipse.ui.texteditor.IDeleteLineTargetExtension.deleteLine(IDocument, > ITextSelection, int, boolean) OK - IDeleteLineTarget is not API anyway as its is package private. I removed IDeleteLineTargetExtension but left the public method in TextViewerDeleteLineTarget, clarifying the meaning of the passed selection. > - Column Mode Font ==> Text (Editor) Column Mode Font DONE. > - XXX should TextSelection open its document to subclasses? */ > ==> I think it's OK to make it protected DONE. > - access to widget in propertyChanged should be protected against being > disposed > - org.eclipse.jface.text.IColumnTextSelection.getRegions() and getText() look > like helpers. Do we really need this in the interface? getText(): only adds some doc stating the nature of the returned text - the method is declared on ITextSelection. getRegions(): true, there are no clients so far. On the other side, typically clients want to know which document regions are covered by a selection. For linear selection, this information is provided by the offset / length pair, for column selection, we need to provide it somehow else. > - org.eclipse.jface.text.SelectionProcessor: I'm declined to make this API. So > far only two methods are used outside jface.text > ==> we could put the must-have methods into JFaceTextUtil for now Hmmmm... there aren't any real clients. CaseAction uses it, but really only because of ITextSelection's ... well ... peculiar definition of emptyness. I only moved this to API in order to get around the errors. DONE: moved it back to internal and added two predicates to JFaceTextUtil. > - replace outdated 3.3 occurrences with 3.5 > - icons: I assume you also see those as placeholders that we will repalce with > icons from the designers Certainly. > - tool bar: Toogle Column Sel... ==> 'Enable Column Mode' > - we no longer use hoverIcon > ==> remove from icons dir and from plugin.xml > - as you already marked: some classes need Javadoc DONE. > - help doc is needed Not done yet.
>Well, the risk is that some concrete editor may have some actions that >implicitely expect a linear selection I guess users (who explicitly switched to column mode) would then detect this and report a bug. The only thing we must have is a protected method where an editor can disable column mode if required. Tom, given your latest patch, once bug 257237 is fixed I'd like to commit the current state and then work on the remaining issues one by one. Do you agree?
(In reply to comment #60) > I guess users (who explicitly switched to column mode) would then detect this > and report a bug. The only thing we must have is a protected method where an > editor can disable column mode if required. OK to make block selection an opt-out rather than opt-in feature. > Tom, given your latest patch, once bug 257237 is fixed I'd like to commit the > current state and then work on the remaining issues one by one. Do you agree? +1 after that opt-out method is re-added. I'll also see if I can solve the undo/redo problems in an easy and transparent way, but I am fine with committing the current state so that early adopters can start to play. Just noticed that the patch also contains quite some clean-up code adding final modifiers to fields... I will of course remove those before committing.
Tom, feel free to commit when ready. Just give me a heads up before to avoid conflicts.
Fixed > 20090113 I released the patch (attachment 121140 [details]) with minor modifications, most notably I re-added the protected method to AbstractTextEditor that allows sub-classes to opt-out of block selection switching. I filed the following bugs to track the issues noted in comment 55: - bug 260921: [typing] undo does not fold events in block selection mode - bug 260922: [dnd] text drag and and drop does not work in block selection mode The issue with modifications in whitespace beyond EOL is essentially covered by the SWT bugs #257237 and #21000.
Thanks again Tom!
Hi Tom, the column mode patch that one can install from http://tkilla.ch/column_mode appears to be broken all of a sudden -- I tried it both on a fresh 3.4.1 and a fresh 3.4.2 installation, and Alt+C does not work as before (where "before" means a few months ago). Have you changed anything on the update site, or am I fooling myself? In my old 3.3M6 installation, Alt+C still works... We need a solution urgently, because we're planning to update the entire software department to 3.4! CU Arno
(In reply to comment #65) > the column mode patch that one can install from http://tkilla.ch/column_mode > appears to be broken all of a sudden -- I tried it both on a fresh 3.4.1 and a > fresh 3.4.2 installation, and Alt+C does not work as before (where "before" > means a few months ago). > > Have you changed anything on the update site, or am I fooling myself? In my old > 3.3M6 installation, Alt+C still works... Hi Arno, the binary patch provided by above site only works for 3.4, not for 3.4.1 or 3.4.2. There is a testing version for 3.4.1 (but again not 3.4.2) available from http://tkilla.ch/column_mode/test. Porting the code to 3.4.2 is trivial, however, providing an update site that works for all 3.4.x versions at the same time is challenging given some Eclipse P2 ... well ... characteristics. Given the fact that column mode made it into 3.5, I don't feel too inclined to invest much time into the 3.4 patching effort.
> Hi Arno, the binary patch provided by above site only works for 3.4, not for > 3.4.1 or 3.4.2. There is a testing version for 3.4.1 (but again not 3.4.2) > available from http://tkilla.ch/column_mode/test. Thanks for the info! However, both patches are compiled with a JDK 1.6 compiler, and thus don't run in an 1.5 JRE :-( We're currently bound at an (IBM) 1.5.0 JDK... I assume you're not really inclined to recompile the 3.4.1 patch with an 1.4 or 1.5 compiler? CU Arno
