Community
Participate
Working Groups
editors capability to select text in block (column) or normal mode
selection support is provided by the StyledTextWidget. Moving to SWT
This is not in plan for R2.0
Moving from Later.
Suggest you use alt-mouse1 to start block (column) selection.
Assigning to LK. Investigate and advise.
Not for 2.1.
Reassigning to SWT Inbox since OTT taking over StyledText.
Block editing should ideally support the following: cut copy paste delete move (with drag and drop) fill block with string (option to replace or insert selected text) fill block with number (option to replace or insert selected text) TextPad has an excellent implementation of all this and should be used for a model for implementation.
This one's been around for 3 year. Any chances of this making it in? I'm tired of copying text into SLickEdit to do block editing and then copy back into Eclipse.
come on guys. i'd spent all my votes on this if buglzilla would let me, just to bump it up on your prio list.
comment 9: i'm with you on this one - i switch to emacs just to do column editing.
Adding my vote for this. We use the styled text widget for our editor (not the java editor) in eclipse and this is annoying. A number of our customers have asked for this as a feature enhancement so that they can switch off of slickedit.
(In reply to comment #0) > editors capability to select text in block (column) or normal mode > I too add my vote to this. Block select is very useful. A real feature.
I vote for this feature as well. This is probably the only feature I really miss since moving off of SlickEdit.
Created attachment 57347 [details] org.eclipse.swt.diff.txt Patch against org.eclipse.swt HEAD of 20070123, including a test snippet. The goal of the patch is to have a starting point for discussing implementation, APIs and semantics of column mode. Please comment. The patch implements column mode support in StyledText, including the following features: - rectangular selection API, conversion from rectangular to normal selection - rendering of rectangular selections (StyledTextRenderer.java) - navigation actions, including caret positions in the white space beyond the end of a line - editing actions (insert, delete, copy, paste...) Notes: - The patch will currently only work on the win32 platform, as the averageCharWidth field of StyledTextRenderer is needed. It should be trivial to adapt on other platforms (one-liner in TextLayout.java). - The column selection is stored as two pixel offsets from the left border. This has been chosen over storing character offsets as column selections may extend into the whitespace beyond the EOL, and in order to accommodate non-fixed-width characters and tabs in monospace fonts. It follows that column mode selections are visual in their nature: changing the font or tab width will change the "normal" selection that a certain column selection corresponds to. - Every column selection has exactly one corresponding "normal" selection; this allows to switch back to normal mode at anytime and provides a compatibility layer for any clients that do not know about column mode. Different column selections may map to the same "normal" selection, however. - Performance: large column mode selections may be time-consuming to compute due to their visual nature. However, there is no performance impact on normal, non-column-mode operation. - I am working on bug 19771 at the same time; the column mode APIs in StyledText are driven from what appeared to be needed for text editor implementors.
Tom, there are a lot of changes for us to review. One thing that is a problem is that your code only works with monospaced fonts. Also, as we discussed, we envisioned block selection to be separate from the selection. For example, in Word, when you block select, it draws a rectangle and any character that intersects is copied or cut. If you type a character or paste in a block selection, it is ignored. We believe that this would be way simpler to implement, rather than trying to reuse the seletion. Steve & Felipe
(In reply to comment #16) > Tom, there are a lot of changes for us to review. I guess :-) > One thing that is a problem > is that your code only works with monospaced fonts. Copying works well with any font kind - and inserting with monospace fonts is inherently problematic, as the insertion point on each affected line changes with every edition. Many applications choose to switch to a monospace font in column mode for that reason (e.g. UltraEdit), which is also recommended by the StyledText.setColumnMode(boolean) Javadoc. The patch I am preparing for bug 19771 will be switching to a monospace font when column mode is enabled. > Also, as we discussed, we envisioned block selection to be separate from the > selection. For example, in Word, when you block select, it draws a rectangle > and any character that intersects is copied or cut. If you type a character or > paste in a block selection, it is ignored. We believe that this would be way > simpler to implement, rather than trying to reuse the selection. I agree that this would be simpler to implement - but I also believe that such a functionality would be *useless* in most places where StyledText is used today within the Eclipse SDK. While simply copying a rectangular selection may make sense for a word processor such as Microsoft Word, a programmer typically wants to insert characters on each selected line. Typical use cases are: - inserting a space on each line (in order to indent the lines) - inserting "this." in front of a number of Java field accesses - changing the "select" clause of a number of similar SQL statements Note that this is the way most or all programming editors work, including UltraEdit and IntelliJ IDEA. Many others are listed in bug 19771 comment 25. This is also the interaction that is simulated (without being able to really draw the selection) by the columns4eclipse (http://columns4eclipse.sourceforge.net/) plug-in. I am sure that simply implementing the "copy" functionality will not satisfy the voters of neither this bug nor bug 19771. Please reconsider - I will attach a patch that fixes a couple of problems and also makes the tests run through.
Created attachment 57685 [details] org.eclipse.swt.diff.txt New patch against HEAD of 20070129. This fixes a number of minor navigation bugs, and also makes the tests run successfully (the StyledTextContent used for testing did not adhere to the API spec of StyledTextContent#getLineCount()).
Felipe / Steve / re. comment 16 What is your assessment of this? Is it possible at all to get a patch of the given size in before the API Freeze for 3.3 (stated to be March 23 in [1]), or is this completely unreasonable? I understand that reviewing the patch will take some time and I am not asking for a final decision - I just would like to know whether I should push on with the effort. We will not provide a patch that merely implements copying, as this does not solve our problem. [1] 3.3 Release Plan: http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release#Milestones_and_Release_Candidates
Created attachment 65346 [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.
Hi Filipe, we have a strong customer need for this feature. Column mode editing is used extensively in embedded development, especially when dealing with bit patterns in C code and such. Please let me know if there is anything we can do to help.
Doug, the block selection you need is the same that Tom needs ? Or is it the same as MS Word implements ? Basically the difference is that Word doesn't allow you to type or paste (insert text in general) when the block selection is up, you can copy or move the block around but you can't type.
(In reply to comment #22 in support of comment #17) I fully support Tom's view in comment #17 I am using Eclipse for embedded development and my vote would be for a monospace type solution with (at least) the funcitonality in #17. MS Word type column mode is pretty much useless for programming and should not stop implementation of monospace column-mode functionality.
I also support the view in comment #17. I guess Doug Schaefer in comment #21 is also talking about column mode in a monospaced sense, as that is what programmers tend to need.
This is the most-watned editor feature here. Is there any plan / progress on reviewing Tom's patch? Our use case is assembler for LIW processors where multiple instructions exist on a line. Developers frequently want to reorder blocks of instructions without have to copy and paste each instruction individually. This is currently very tedious in Eclipse (though the feature is supported in most programmer's editors).
As an embedded developer I would like to give my point of view on this subject: For the past 10 years I have been using the ancient CodeWright on windows as my primary code editor. Borland bought the company and canceled CodeWright a few years back, but it is still the strongest code editor I know of. SlickEdit seems to have the features, but it's not opensource, and I don't want another editor that is bought and canceled by a mastodont again. I have partly changed my work environment from windows to ubuntu over the last 6 month. Partly because I still haven't found an opensource editor with the superb coding features and ease of use, as in CodeWright. The block editing features are the main reason why I still use CodeWright. And it's very annoying to have to switch to a vmware windows session whenever I need to do some power editing. Here's a description of the features I use the most: Right click and drag -> marks a block anywhere. Ctrl+B -> starts keyboard block marking. Del, Backspace, Cut -> delete/cut block, truncate block to nothing. Copy -> Copies block for special paste. Paste into block -> Overwrites selection. Paste copied block -> insert block with top left at cursor. After insert cursor is moved to bottom left. This allows for easy insertion into of many rows. Tab/Shift tab -> indent/deindent from left column of block. Nice for manual code formatting. Menu block/selection commands: Upper, Lower -> Change case. Left, center, right justify -> Text justification. Enumerate -> Nice feature that enumerates block columns. E.g. 2 character block enumerates from 0 to 99, then rolls over. If first row contains a number it enumerates from there. Comment -> Format's block into comment, according to language settings. A single feature I always missed: Sort lines in block. Another strong feature I use a lot is the keyboard macro recording: E.g. A customer sends me a spreadsheet with names and ask me to put them into a database. I simply copy them into the editor and use the macro recording function while I change the first line into an sql insert statement, and then simply run that macro on the following lines. At last I have a CopyAppend function assigned to Alt+A: That is very helpfull for collecting function names to put in header files or documentation. I don't know if something like that is already possible in Eclipse? There's a lot more powerful features, but those here are the block features a really miss in all other editors. Of course monospace fonts is required for this to work, but I'm always using monospace for source code. Of course another solution for me would be if I simply could make the dialogs work under wine... (Preferably
A patch is available, 37 votes on this bug, 58 votes on bug 19771 which is blocked by this one, and 21 duplicates of bug 19771... what's still blocking this? C'mon SWT team, you're not all on Cocoa, are you? Or is there anything we can do to help you get started reviewing the patch?
I don't think there's a dispute that this is a much needed feature, especially for embedded systems development that deals with a lot of binary literals. It's just whether we can get the committers to help us get this in. And that's based on their priorities, not ours. Are we all happy with Tom's patch? Are there any more changes necessary to make it acceptable to the committers? BTW, sorry for missing the previous comments. I guess I didn't make the CC list. But, yes monospace is what we're asking for. And as others have mentioned, there are plenty of editors that do this already that we can use as examples.
Yeah. Given that 99.9% of code development is done in monospace, let's focus on that.
> Are we all happy with Tom's patch? Definitely. many of my colleagues use it every day and are perfectly happy. The only bad thing is that the patch is only for 3.3M6 which seems (with an emphasis on "seems") to have some bugs which were fixed in 3.3.
(In reply to comment #30) > > Are we all happy with Tom's patch? > > Definitely. many of my colleagues use it every day and are perfectly happy. The > only bad thing is that the patch is only for 3.3M6 which seems (with an > emphasis on "seems") to have some bugs which were fixed in 3.3. > I'm happy too with Tom's patch and plugin for 3.3M6. It's possible to release it as plugin for 3.3.1.1? It would be nice to have it in 3.4 too!
(In reply to comment #31) > I'm happy too with Tom's patch and plugin for 3.3M6. It's possible to release > it as plugin for 3.3.1.1? It would be nice to have it in 3.4 too! 3.3M6 definitely has some memory problems if you have MANY markers, so I'd urgently like to upgrade to 3.3, too. Is there any chance that the patch be ported to 3.3?
(In reply to comment #15) > - The patch will currently only work on the win32 platform, as the > averageCharWidth field of StyledTextRenderer is needed. It should be trivial to > adapt on other platforms (one-liner in TextLayout.java). What exactly is this "one-line change"?
Created attachment 91877 [details] Incomplete patch against 20080307 HEAD. This patch is INCOMPLETE. Column selection "kinda" works. Unlike attachment 65346 [details], this _only_ patches StyledText and StyledTextRenderer. I figured there's no point trying to port the rest to HEAD if the SWT side hasn't been completed.
Created attachment 91878 [details] Screenshot depicting the problems with attachment 91877 [details]. As you can see, it gets kind of flaky if you try to move your mouse around in diagonals. There's been some key changes in StyledTextRenderer that has made it difficult for me to port Tom's patch to HEAD (SWT is completely foreign to me). If any one of you want to build on top of my patch above, have at it.
I am also a longtime CodeWrite user, and severely miss the block select feature when using Eclipse. I am impressed with the whole system, but having to move code back and forth between CodeWrite and Eclipse is getting really old. Please make this requested feature a plugin. Our whole engineering staff will use it. There are many other features of CodeWrite that I would like to see implemented in Eclipse, but the block select is critical for being able to develop embedded software. Thank you.
It would be very nice to make this issue... I miss this feature too, it's very useful and very important for me. Eclipse IDE users needs block selection... Thanks for keeping working... Hope it'll be out very soon.
Created attachment 108502 [details] column_mode.zip By popular request: column mode for Eclipse 3.4. The file "column_mode.zip" contains icons and a patch against the following plug-ins, also covering bug 19771: org.eclipse.swt org.eclipse.jface.text org.eclipse.ui.workbench.texteditor org.eclipse.ui.editors org.eclipse.jdt.ui For Eclipse 3.4 users, there is also an update site at http://tkilla.ch/column_mode which offers feature patches containing the patch. Have fun...
Great, it simply works as expected (Ultraedit-like). Thank you, Tom! Ok, all the other selection-based plugins has to be updated to support columns selection actions (my plugins too), but alone the ability to use it "as is" is great addition to the platform. At least nothing breaks, if trying to run external, not patched code, it just assumes that "usual" selection is there. @SWT team: any chance to get this patch integrated into 3.5? Any plans to do it at all?
Hello, I was really happy that this update site appeared but unfortunately I can't install it. Here is how I proceed : 1) I unzip Eclipse 3.4 SDK for win32 2) I open it and add http://tkilla.ch/column_mode update site 3) I install the 3 features under this update site 4) Eclipse asks me to restart Ecilpse, what I do. 5) Eclipse doesn't start : it displays me an error that refers to this log : eclipse.buildId=I20080617-2000 java.version=1.5.0_09 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_FR Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY org.eclipse.osgi 4 0 2008-07-28 09:11:36.607 !MESSAGE An error occurred while automatically activating bundle org.eclipse.ui.workbench (158). !STACK 0 org.osgi.framework.BundleException: The activator org.eclipse.ui.internal.WorkbenchPlugin for bundle org.eclipse.ui.workbench is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:146) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:980) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:441) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:170) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:867) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:188) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:464) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:441) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:141) ... 36 more Root exception: java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:464) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:441) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(AbstractBundle.java:141) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:980) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:427) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:441) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:170) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:867) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:188) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) Am I doing something wrong ? Some of you said that it works, do you know why I can't make it work ??? Is it a Java version problem ? Thanks for your help.
From your traceback: Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file It looks like the update site was generated with a newer Java compiler (likely 1.6) than you have installed (likely 1.5 or 1.4) -- install a new JDK and you should be good to go.
Any chance of releasing a version compiled with Java 1.5? Simply installing a new JDK/JRE isn't a option when a thousand computers would need to be upgraded.
Indeed it would be so nice if a version could work under Java 1.5 ! How can I integrate this feature on a software used by other developpers but under Java 1.5 mandatory... ? Do you absolutely need Java 1.6 to compile this patch ?
(In reply to comment 40, comment 42 and comment 43) I will push 1.4 compliant binaries as soon as I find some time (which may not be soon). The patch does only require Java 1.4 - I was only hit by the fact that PDE export does not look at the project's compiler preferences when exporting... In the meantime... Java5 has already started its End-Of-Life process ;-)
Another small issue with the last patch from Tom (unrelated to the columns mode itself) is, that after installation, you cannot browse source code of patched plugins: org.eclipse.ui.editors org.eclipse.swt.win32.win32.x86 org.eclipse.ui.workbench.texteditor org.eclipse.jdt.ui So if you are using patched Eclipse installation as PDE target platform (default setting), it will unfortunately make you unhappy during Eclipse debugging/source code browsing... The solution is to change the target platform or include source code for patched plugins together with plugins or finally integrate this patch to the Eclipse itself. I've used the patch for "usual" PDE development on both Linux/Windows and didn't found any problem so far, so personally I'm wondering why is there no feedback from SWT team about the future of this bug.
Hi SWT team, can you please give some feedback on the state of this bug? - patch is available - it works fine, so far no negative side effects reported - very popular bug request, see number of votes Are there any problems with the patch??? Any plans to fix this bug it at all?
First of all, sorry it took us so long to get this. We are hoping to address this for 3.5. The patch is character based which means it will draw properly when the font is variable pitch or when the StyledText widget is multi-font. The patch inserts white spaces, which can be bad when comparing CVS changes. Furthermore, it uses selection, which draws wrong for BIDI text. I am investigating a pixel based approach that should not have these problems and should have the same behavior as the patch.
> which means it will draw properly when You mean it will not draw properly.
(In reply to comment #47) > We are hoping to address this for 3.5. Cool! > I am investigating a pixel based approach that should not have these problems > and should have the same behavior as the patch. I agree that pixel-based is the way to go, as a rectangular selection is inherently pixel based. It must just be easy to derive the covered character ranges for clients from the pixel based selection. > The patch is character based which means it will draw properly when the font is > variable pitch or when the StyledText widget is multi-font. The patch inserts > white spaces, which can be bad when comparing CVS changes. I understand that inserting spaces may not always be expected - but IMO it is still the most intuitive behavior when modifying / deleting a rectangular selection. Perhaps this behavior could be separated into another API that allows "virtual positions" over the end of line similar to some word processors?
> Perhaps this behavior could be separated into another API that allows "virtual > positions" over the end of line similar to some word processors? See Bug 21000
We released a first version of the pixel based selection. It is working ok for standalone StyledText but there are problems in the integration with JDT, for example: a) removing a tab from the beginning of several lines, there is code in JavaAutoIndentStrategy#customieDocumentCommand that re-inserts the tabs I'm trying to remove to preserve the indent -- can be disabled in java->editor->typing pref page, uncheck adjust indentation when pasting b) add a tab to the first offset of a line that starts with tabs. JavaEditor sets the caret offset to the first non-tab char in the line and stops the keydown event. --fails because all setSelection() are no-op when blockSelection==true -- can be disabled in java->editor->typing pref page, uncheck tab adjusts the indentation of the current line ----- The API is also under construction. For now, we only have setBlockSelection(boolean), getBlockSelecion(), and invokeAction(ST.TOGGLE_BLOCKSELECTION). I'll attach a sample code. Tom: can you investigate ?
Created attachment 113771 [details] sample code
I've looked at the StyledText code released after M2 and it looks promising! I like the dual mode of selecting character-based when the caret is within text, and pixel-based when it is not. As for the problems you mention: IMO you shouldn't worry too much about JavaEditor doing strange things, as there will always be situations where the clients of StyledText don't want to rely on the default actions in the widget but rather want to run their own story. The real solution here is to support querying and setting the block selection for StyledText clients. Without that, there is not much chance of a real-life fix for bug 19771.
Hi Tom, what APIs do you need from SWT to fix bug 19771 ? Here some ideas I have for new APIs: void setBlockSelectionRectangle(Rectangle) Rectangle getBlockSelectionRectangle() int[] getBlockSelectionRanges() --the ranges array contains start and length pairs of the text in the block selection. void insertBlockSelectionText(String text) --replaces all ranges in the block selection with 'text' As for the existent APIs we still need to decide what makes more sense when the block selection is up: setText() - does it reset block selection mode to false ? insertText() - inserts at the caret offset or at the blockSelection ? setSelection(int) setSelection(int, int) setSelection(Point) setSelectionRange(int, int) - ignored or reset block selection mode to false ? setCaretOffset(int) - reset block selection mode to false ? Other item to think about is: events - should StyledText send Selection events when the block selection is changing ? ---- Tom M3 is October 31st - do you think we can have this finished for M3 ? I'll give you full support from SWT.
(In reply to comment #54) > M3 is October 31st - do you think we can have this finished for M3 ? I'll give > you full support from SWT. Hmm... sounds rather ambitious on my side to get everything done, since I am doning this in my spare time. However, I am optimistic to can get something done by that time that will allow us to more or less freeze the APIs involved. > void setBlockSelectionRectangle(Rectangle) > > Rectangle getBlockSelectionRectangle() Sounds good - I assume, the rectangle would be a pixel-based selection? > int[] getBlockSelectionRanges() > --the ranges array contains start and length pairs of the text in the block > selection. This would be handy, but not absolutely necessary - otherwise, we'll have to code a utility that provides that, and StyledText may be able to provide that more efficiently. > void insertBlockSelectionText(String text) > --replaces all ranges in the block selection with 'text' Perhaps - although I would rather expect the insertText() method to do that. > As for the existent APIs we still need to decide what makes more sense when > the block selection is up: > setText() - does it reset block selection mode to false ? I tend to say no, but not sure. > insertText() - inserts at the caret offset or at the blockSelection ? At the block selection - otherwise, we'll have to intercept all typing commands in text land and replace them with a call to insertBlockSelectionText. The same goes for all editing actions like doContent(), cut, copy, delete, backspace... IMO, the contract of all these operations is that they operate on the current selection - if these do not understand block mode, it will stay something artificial, but users expect that block selections work the same as a normal selection (apart from the obvious difference). > setSelection(int) > setSelection(int, int) > setSelection(Point) > setSelectionRange(int, int) - ignored or reset block selection mode to false ? > setCaretOffset(int) - reset block selection mode to false ? It should probably be OK to reset the block selection to false. My patch does some magic in this case, because tooling not aware of block selection will constantly reset block mode - not really what the user expects. But in most Eclipse editor cases, the StyledText widget is not exposed to other tooling, so this problem should be manageable. > Other item to think about is: events - should StyledText send Selection events > when the block selection is changing ? Of course! Looking at the original patch, I would also vote for the two following APIs: boolean isLocationSelected(Point location) boolean isSelected(int offset) These would make the client's life much easier, albeit they could probably be substituted by some utilities. -tom
>> void setBlockSelectionRectangle(Rectangle) >> Rectangle getBlockSelectionRectangle() >Sounds good - I assume, the rectangle would be a pixel-based selection? Yes, relative to the client area. >> void insertBlockSelectionText(String text) >Perhaps - although I would rather expect the insertText() method to do that. Okay, insertText() would do that. >> Other item to think about is: events >Of course! Note, in a regular Selection event the x and y are set with selection start and end. That doesn't map well with block selection. the application code will need extra logic to handle that. All setSelection* API will reset block selection mode. >boolean isLocationSelected(Point location) >boolean isSelected(int offset) I'd say no here. they are both easy to implement by the application, the first using styledText.getBlockSelectionRectangle().contains(location) and isSelect using isLocationSelected(styledText(getLocationAtOffset(offset))) I'll get Steve or Silenio to okay the APIs, I'll let you know when it is ready.
(In reply to comment #56) > >> void setBlockSelectionRectangle(Rectangle) > >> Rectangle getBlockSelectionRectangle() > >Sounds good - I assume, the rectangle would be a pixel-based selection? > Yes, relative to the client area. Just to make sure I understand correctly: does that mean that the returned block selection is relative to the visible viewport area, or the 'virtual' area covered by the entire styled text content? I would strongly favor the second, unless we want to have to deal with negative rectangles, a block selection that changes when scrolling, and more conversion code for all clients. The block selection, while pixel-based by nature, must not have any dependencies on scrolling!
>> M3 is October 31st - do you think we can have this finished for M3 ? I'll give >> you full support from SWT. >Hmm... sounds rather ambitious on my side to get everything done, since I am >doning this in my spare time. However, I am optimistic to can get something >done by that time that will allow us to more or less freeze the APIs involved. Note that Tom and I agreed on M4 for this and that's also how it is reflected on the Platform Text plan, but as you can see interaction is also possible during M3.
(In reply to comment #57) Relative to the client area means relative to the visible viewport area. Yes, you'd have to handle negative x and y. Yes, x and y will change when the text is scrolled. IMO, this makes sense because it is consistent to all other APIs in StyledText, see getOffsetAtLocation(point), getLocationAtOffset(int), getTextBounds(int , int). All relative to the client area. And so are the event.x and event.y during mouse down and move (and other events). If you need the rectangle in absolute coordinates, it is easy enough: rect.x += styledText.getHorizontalPixel(); rect.y += styledText.getTopPixel(); Why do you need setBlockSelectionRectangle/getBlockSelectionRectangle ? Where/How do you plan to use it ? I just would like to understand why you prefer absolute coordinates.
(In reply to comment #58) > Note that Tom and I agreed on M4 I didn't know that but it is fine. My intent is to finish SWT by M3 so that Text/JDT and other client have time to finish their code for M4.
(In reply to comment #59) > Why do you need setBlockSelectionRectangle/getBlockSelectionRectangle ? > Where/How do you plan to use it ? I just would like to understand why you > prefer absolute coordinates. Hm, I was just going off in a big rant about how one could possibly think that a selection that changes when scrolling would make sense... :-) but, thinking again, I believe I understand better now. You would consider the proposed int[] getBlockSelectionRanges() as the block-counterpart of getSelectionRange(), and look at getBlockSelectionRectangle() only as additional information about the exact pixel location of the selection. That makes sense, and would work fine in many places (for example when determining whether the user is dropping a drag into the selection or not). ---- Playing around with the block selections, I noticed the following issues (I know this is just a first cut, just noting these down): - the selection color - I understand this may just be the current implementation to draw the selection over the widget using alpha. Do you plan to later change this to actually draw a proper selection? - that would make for a much smoother story! - inserting text when the insert location over the EOL - we really need to find a decent solution here. Not unexpectedly, I still favor bug 21000, but I am open for other good suggestions. - the block selection can be expanded over the right edge of the editor area. - any key handling beyond the basic arrow keys Shift+{END, HOME, PG_DOWN, PG_UP}, Ctrl+Shift+Arrow... - DND - drawing of the caret - converting the selection when toggling the selection mode - when using the arrow keys to expand the selection over EOL, the spacing is too big - it should use the average char width, which has the advantage to make the probable use case - mono-spaced fonts - work nicely. - it is not always clear, which parts of the text really fall into the selection. While it looks nice to have a smooth rectangle, it might be more useful to actually draw the selection on the characters that are really selected.
(In reply to comment #61) > While it looks nice to have a smooth rectangle, it might be more useful to > actually draw the selection on the characters that are really selected. What about two colors: normal selection color for the characters actually being selected (such that EOL's are visible, and it gets obvious where selection starts in case of proportional font), and an Alpha selection for the actual exact rectangle?
>such that EOL's are visible StyledText does not show them but I agree it would be handy. Showing whitespace is built on top of StyledText.
Fixed > 20081006 We think that we (SWT) are "done" with this bug report (ie. block selection has been implemented, but it is missing features and has bugs). At this point, we should be tracking work for individual items in Bugzilla, rather than using this bug report (otherwise, we can never close this bug). (In reply to comment #61) > You would consider the proposed > int[] getBlockSelectionRanges() > as the block-counterpart of getSelectionRange() Okay, but need a bug report that describes (quickly) why this is needed. There is an issue as to whether "block selection" will replace "selection" as the general API. If this is the case, then getBlockSelectionRanges() may be renamed getSelectionRanges() etc. We are not trying to be difficult but we need to keep the amount of API to the minumum. We don't want to add API that doesn't get used. > - the selection color - I understand this may just be the current > implementation to draw the selection over the widget using alpha. Do you plan > to later change this to actually draw a proper selection? - that would make for > a much smoother story! No, I don't plan changing that. That would need TextLayout support to draw pixel based selection, and that is not support by the underlying technologies (pango, atsui, nslayoumanager, etc) > - inserting text when the insert location over the EOL - we really need to find > a decent solution here. Not unexpectedly, I still favor bug 21000, but I am > open for other good suggestions. Agreed, but this is not API we should not stop us now. Lets open a separate bug for it. > - the block selection can be expanded over the right edge of the editor area. This is a bug, I'll fix that. > - any key handling beyond the basic arrow keys Shift+{END, HOME, PG_DOWN, > PG_UP}, Ctrl+Shift+Arrow... Another bug, do you need all the keyboard action to work in block Selection ? page up, page down, word previous, word next, text start, text end, window start, window end, line start, and line end. I would think line, word, and maybe page would be enough. Note. it is also missing mouse gestures like, double click, double click draw, tripe click. > - DND Yeap, need to enter a bug for that too ;-) > - drawing of the caret Okay, I decided to hide the caret when the block selection up. When the block selection is up it is the insertion point, having the caret blinking on the last line was a bit confusing/distracting IMO. TextEditor is Mac works the same way. > - converting the selection when toggling the selection mode Do we need that ? This can be done by the application, you can use getBlockSelectionRanges() to convert Block Selection -> Normal Selection. > - when using the arrow keys to expand the selection over EOL, the spacing is > too big - it should use the average char width, which has the advantage to make > the probable use case - mono-spaced fonts - work nicely. Okay, I don't mind changing that. > - it is not always clear, which parts of the text really fall into the > selection. While it looks nice to have a smooth rectangle, it might be more > useful to actually draw the selection on the characters that are really > selected. You are basically suggesting going back to character-based ;-) MS Word has the same problem. The solution here is use a monospaced font.
>At this point, we >should be tracking work for individual items in Bugzilla, rather than using >this bug report (otherwise, we can never close this bug). Agreed. Tom, if you file bugs that are needed in order to fix bug 19771 then please cc me and mark it as blocking bug 19771.
Ok. I split off the following bugs: - bug 250170: alpha selection X bug 250171: getBlockSelectionRanges API X bug 250172: insert behavior over EOL - bug 250173: block selection expanded over right edge X bug 250174: key handling X bug 250175: DND - bug 250176: caret drawing X bug 250177: conversion of block to linear selections and back X bug 250178: change the keyboard increment to match average char width X bug 250179: consider drawing block selection on characters X bug 250180: don't reset block selection mode The ones marked with an X above are currently blockers for a successful and complete implementation of bug 19771 - we need to discuss which ones can be worked around.
*** Bug 76451 has been marked as a duplicate of this bug. ***
