Community
Participate
Working Groups
May seems trivial but it is the preferred way of editor behavior for me. If the line contains no characters I still want to be able to place the cursor anywhere on the line. If I type at some position beyond the line end, the preceding characters on the line are filled automatically with spaces. Allowing this behavior when I scroll through the text the column of the cursor is not changed and I don't loose focus on that column part of the source I'm reviewing, too.
I think clearing spaces (and tabs) at the end of line would also be beneficial if we are not going to have the cursor default to end of line. Originally when I was going to submit this (and maybe even offer to help), I was merely going to suggest that as you cursor past lines with less columns than where you started it does not reset what column you are on. I like your idea as well -- but It did make me think about how I hate seeing extra spaces and tabs at the end of a line. Does anyone have any additional thoughts on this? I'd love to work on it -- although my time is very limited. I'll check back.
*** Bug 59237 has been marked as a duplicate of this bug. ***
*** Bug 69742 has been marked as a duplicate of this bug. ***
*** Bug 77931 has been marked as a duplicate of this bug. ***
Ditto! Jumping cursor keeps current column hard to keep track of when scrolling up and down in code. TextPad has this feature and its called "Constrain the cursor to the text".
*** Bug 124879 has been marked as a duplicate of this bug. ***
If somebody could implement this, they surely deserve at least a dozen of beers. This is more than a feature enhancement request. It just does not make sense that one can position the cursor anywhere on a line which happens to be full of (invisible) spaces, but can't do the same on another line, when visually the two lines look exactly the same.
Moving to SWT for comment. That's not something we would want to hack on top of StyledText.
My initial position is WONTFIX. It seems like a very uncommon feature. If you wish to prototype a solution, go ahead. I suspect that attemping to implement this will make the code very complex.
I cannot comment on the complexity, but I agree that if has not been planned for in advance, it will be probably difficult to add. It is a pity, though. It is not such an uncommon feature. The KDE text editors support it. So do Microsoft's IDE's and Borland's. It was the default in all Borland editors when I last used them (admittedly this was years ago), so I am sure there are many developers that have gotten used to it and miss it. I know a couple and at least one who decided not to use Eclipse+CDT on account of the text editor (but of course birds of a feather ... :-) If for example NetBeans supported it, I would (very unwillingly) consider switching. It is just so much easier (for me) to navigate the source when the cursor doesn't jump around. It is all very subjective, of course. Perhaps a relatively simple solution would be to combine it with an option to remove trailing spaces (which is a very useful on its own anyway. AFAIK, there is no programming language or editable file where trailing spaces are desirable, so it should be the default). Once you have automatic removal of trailing spaces, you can afford to generate spaces automatically whenever the cursor attempts to move outside of the boundaries of a line. The existing code doesn't have to change that much.
I agree with Steve, I tested quite few text editors and IDEs on Windows, Linux, and Mac and this features is not common (honestly, the ones I tested none implemented it).
i would kindly ask you to look also at: MS Visual Studio (all versions) Borland Pascal / Delphi / CBuilder (all versions) UltraEdit phpEd Homesite and many, many more. whould it be taken into consideration, if we would provide at least a dozen well known IDEs or editors wich do it traditionally? for me, this is a K.O. kriteria, which unfortunately not allows me to use eclypse at all. and that for years! those jumping cursors totally drive me crazy while trying to comply with some column-based coding-standards like this: $out .= '' .'<textarea ' .'name = "'.$this->name.'" ' .( $this->id ? '' .'id = "'.$this->id.'" ' : '' ) .'class = "'.$this->getCssClass().'" ' .'rows = "'.$this->rows.'" ' .'cols = "'.$this->cols.'" ' .'wrap = "virtual" ' .( $this->readonly ? '' .'readonly ' : '' ) .'style = "' .'width : '.'100%'.'; ' .( $this->controlStyle ? '' .$this->controlStyle :'') .' "' .( $this->controlHint ? '' .'onMouseOver = "return overlib(\''.$this->hint.'\', HAUTO, VAUTO);" onmouseout="return nd();" ' : ' ' ) .( $this->onChange ? '' .'onChange = "'.$this->onChange.'" ' : '' ) .( $this->onKeyDown ? '' .'onKeyDown = "'.$this->onKeyDown.'" ' : '' ) .( $this->onKeyUp ? '' .'onKeyUp = "'.$this->onKeyUp.'" ' : '' ) .( $this->onKeyPress ? '' .'onKeyPress = "'.$this->onKeyPress.'" ' : '' ) .'>' .$this->value .'</textarea>' ; i promise you, not to be the only one. and it worked in early version of eclypse too! since you overhauled the richText several years ago... this was a killswitch for me. thats all to sad. best regards.
lets not forget TextPad :-) This obviously falls into the 'emacs vs. vi' and 'curly brace on the same line or next line' religious sort of debates. No one is right but everyone has a preference (whether they're aware of it or not). It would be nice if eclispe supported both modes.
I would add to the list of the IDEs - IntelliJ Idea. PL/SQL Developer I also thought the featured worked before in Eclipse, but I was not 100% sure. Comment #10 From T.Mikov proposes to fill each line with spaces. I don't know how the control is currently implemented, but funcionaly I would fill in the line with the spaces only when a user types something after the end of current line. If the user is just scrolling though I would not add spaces, but just keep the cursor at current position. Other important moment is that the cursor should not leave the screen when scrolling via Ctrl+Up/Dn. But it's not related to this topic Comment #13 From analogue@yahoo.com I don't think someone preferres jumping cursor over predictible. Those people are just not picky and happy with whatever available.
analogue@yahoo.com is right. This feature is a preference and it should be turned off by default. This is a big working item and at this point this is not in the plan, so my suggestion to you who really wants to see this feature in StyledText is to write a patch and submit it here. Thanks.
Re: comment 14 from Yuri Thanks for mentioning that IDEA supports this. I guess Borland JBuilder also has it ? Re: comment 11 from Felipe Are you sure that the IDEs you tested didn't support it, or that it was simply disabled ? As was said IDEA, which I guess is Eclipse's direct competition supports it. So do KDevelop, and the Borland and Microsoft IDEs. So definitely the majority of IDEs out there actually support it. Eclipse is the first developer editor that I have ever used which doesn't have it. I use Eclipse because in Java the advantages of Eclipse far outweigh this and Eclipse is free. However it is not so in other languages like C. All the refactoring tools, syntax coloring, etc. are nice, but the most important thing in the IDE is still the text editor and its ability to edit simple text. This is a programmers primary tool of work and it seems to me like it is getting slightly neglected. (For example there isn't an option to remove trailing spaces, so every time one tries to commit, he has to edit the files manually to strip invisible spaces). Anyway, I realize that this is a big task and we are not in a position to demand anything from a (otherwise great) free product. But at least now there is some awareness about this feature. Hopefully it can be included in the plan for later or somebody with Eclipse development experience will pick it up. If I could develop such a patch, I would, but practically speaking, since I have no experience with Eclipse programming, it would probably take me months. Since apparently there is a non-free Java IDE which already has this, it would be more practical to just buy it. (I am not trying to blackmail you guys - I am just one user :-)
SlickEdit also supports this feature. In fact I stopped using eclipse for a very long time until I bought a copy of the SlickEdit Plug-in for Eclipse, which supports this very required and very, very, very common feature of true programmers editors. (*Chris*)
I am sad to say, I have purchased a copy of IntelliJ IDEA (our team will probably standardize on it). "virtual space" is on by default when you install it for the first time.
Hi, the others have stated the need for this quite eloquently. I've only been using Eclipse for a few days, and come from Borland & MS editors, plus UltraEdit. (UltraEdit has an option to automatically delete end-of-line spaces when a file is saved.) Once you get used to this behavior, there's no going back. In my case, I like to add comments, neatly aligned, over to the right of a block of code. The "jumping cursor" can really be distracting, as well as requiring extra work. Sorry I can't help, but please keep an open mind towards adding this feature. Eclipse is wonderful in every other regard and I was very surprised to learn that this was not an option. Many thanks- -David
*** Bug 29859 has been marked as a duplicate of this bug. ***
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
*** Bug 437981 has been marked as a duplicate of this bug. ***
Further editors which support virtual spaces: PSPad, µVision Some of our experienced programmers won't switch to Ecplise since they're missing this feature. I would love adding it myself if I had any IDE programming experience. However, I'm just another embedded-only programmer... :-(
Those jumping cursors totally drive me crazy too. Just try to select something in the long line with mouse, brr... Something like the Russian GULAG - "step left, step right - shot on sight"
Bug has been triaged. Visit https://wiki.eclipse.org/SWT/Devel/Triage for more information.
I personally would like that feature very much and I will provide a gerrit patch shortly, that shows that this is not so complicated as one might think. My solution places the caret directly under the mouse cursor position, if the ALT key (a.k.a. SWT.MOD2) is pressed during mouse down event. But only the caret is placed there, the actual text isn't modified, i.e. no spaces are added to the text. This only happens, if the user presses a character. So no accidental extra spaces are added, unless the 'outside of the text' caret position is actually used. Based on that patch we should discuss some scenarios: 1. How to access that feature? I suggest the ALT key (a.k.a. SWT.MOD2). This is also the way Notepad++ does it. 2. Should it be possible, to place the cursor below the last line? The current patch only supports text lines. The 'below text' case would be more complicated to handle when the user starts to type there, because we not only need some spaces to add in front of the typed text, but also some line breaks. 3. What happens, if the SHIFT-key is also pressed? Both features together doesn't make sense, as one cannot mark characters, that are currently not present. 4. How to handle formatted text? I didn't find a quick solution, to get the width of the space character at a specific line or position of the text. Does someone know that? I need that, to calculate the number of spaces when the 'outside of the text' caret position is actually used.
New Gerrit change created: https://git.eclipse.org/r/100004
(In reply to Conrad Groth from comment #26) > ... the ALT key (a.k.a. SWT.MOD2) ... Sorry, I mean MOD3. MOD2 is the SHIFT key and this is for selecting.
(In reply to Conrad Groth from comment #26) Hi Conrad, thank you very much for your support on this issue! Question 1: Our desired behavior is to have it turned on all the time, i.e. without the need to press the Alt key. (The Alt key might be in use for further menu operations.) Can we use some config setting for turning this feature on/off or binding it to some modifier key (such as SWT.MOD3)? Question 2: From my point of view, this is not needed. Question 3: As I said, I wouldn't bind it to modifier keys. Our main editor (CodeWright 7) supports selecting "untyped white space". I cannot comment on your question 4. Cheers! Ulf
