Bug 35779 - [misc] Text Viewer and Editor needs to support word wrap
Summary: [misc] Text Viewer and Editor needs to support word wrap
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P3 enhancement with 229 votes (vote)
Target Milestone: 4.6 M4   Edit
Assignee: Andrey Loskutov CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted, investigate, noteworthy
: 23579 36589 49776 64439 76777 87617 90912 97767 109034 163761 182861 339272 (view as bug list)
Depends on: 168557 408833
Blocks: 18348 481818 481819 481873 481932 483937 484142 485722 486656
  Show dependency tree
 
Reported: 2003-03-27 15:06 EST by Gary Gregory CLA
Modified: 2019-07-23 09:59 EDT (History)
130 users (show)

See Also:


Attachments
Kate style of line wrapping (44.96 KB, image/png)
2007-04-20 08:06 EDT, Wolfgang Lorenz CLA
no flags Details
Long lines broken on Linux (344.19 KB, image/gif)
2008-12-05 09:53 EST, Andrey Loskutov CLA
no flags Details
The new word wrap plugin in the old 3.7 (238.46 KB, image/png)
2013-02-06 10:12 EST, Gustavo Guillermo CLA
no flags Details
git patch for the master branch of eclipse.platform.text.git (Eclipse Juno 4.2) (5.81 KB, patch)
2013-02-07 14:35 EST, Florian Weßling CLA
no flags Details | Diff
New "Enable word wrap" preference option (66.13 KB, image/png)
2015-11-02 18:09 EST, Andrey Loskutov CLA
no flags Details
RHEL7/GTK2 example with line wrapping and a bookmark (49.39 KB, image/png)
2015-11-10 04:29 EST, Andrey Loskutov CLA
no flags Details
Screencast that shows the wrong behaviour on Mac (14.28 MB, video/quicktime)
2016-01-12 11:16 EST, Matthias Becker CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gary Gregory CLA 2003-03-27 15:06:47 EST
In the text file editor, please add a context menu option to turn word-wrap on 
and off.

Thank you for considering this request.
Comment 1 Dani Megert CLA 2004-03-11 02:55:15 EST
*** Bug 23579 has been marked as a duplicate of this bug. ***
Comment 2 Dani Megert CLA 2004-03-11 02:55:57 EST
To be investigated after 3.0
Comment 3 Dani Megert CLA 2004-05-28 03:56:26 EDT
*** Bug 64439 has been marked as a duplicate of this bug. ***
Comment 4 Dani Megert CLA 2004-10-22 03:23:05 EDT
*** Bug 76777 has been marked as a duplicate of this bug. ***
Comment 5 Jean-Marc N/A CLA 2004-10-22 04:26:17 EDT
Hello Daniel,

Terminology :
- Line Wrapping : Word Wrap in the Eclipse jargon.
- Context menu : Menu that pops up when right clicking an editor window.

I'm not sure bug 76777 is a duplicate of this one. Gary is asking for a context
menu option, I'm asking for a new feature in the Line Wrapping tab. Moreover
would the Line Wrapping (I prefer to use the Eclipse terminology) context menu
option change the Line Wrapping option for all editor windows or only for the
current window ? Context is context, it means it only applies to the current
window. Moreover I thought a bug report should only deal with one feature
request but these are 2 different features. For example only the Auto Line
Wrapping option option could be available at first, then it could be « populated
» to the context menu to set it on or off for the current window. Adding such a
feature to the context menu would mean we should also add many other checkboxes,
options, to it : enable comment formatting, put empty statement on new line... I
think setting the preferences should only be possible from the preferences
dialog, not from the context menu. And IMHO using special preferences for a
single window doesn't make any sense.

So is there a difference between word wrap and line wrapping ? Is the context
menu meant for changing the preferences ?
Comment 6 Dani Megert CLA 2004-10-22 05:50:05 EDT
As you can see from the duplicates there are several ideas on how to do it.
Simply because I resolved your PR as duplicate of this one doesn't mean we're
now doing it exactly as mentioned in this PR and ignore your comments.

At the time when someone decides to implement such a feature all the duplicates
(and other existing bug reports) will be reviewed before coding.

And yes, it's always better to have one feature per report.
Comment 7 Dani Megert CLA 2005-03-10 04:33:30 EST
*** Bug 87617 has been marked as a duplicate of this bug. ***
Comment 8 Dani Megert CLA 2005-04-11 04:41:16 EDT
*** Bug 90912 has been marked as a duplicate of this bug. ***
Comment 9 Ed Burnette CLA 2005-05-17 20:55:08 EDT
This one has been open for a couple years now and has some votes. Comment #2
says it was going to be investigated after 3.0 but it doesn't look like it was.
What's the process for getting it on the 3.2 plan and not latered again at the
end of the 3.2 schedule?
Comment 10 Ed Burnette CLA 2005-05-17 21:06:33 EDT
BTW, the earliest request for this I could find was bug 22713 on 2002-08-22.
StyledText has supported wrap since 2001-10-11 (bug 4610).
Comment 11 Dani Megert CLA 2005-05-18 05:57:10 EDT
Allowing word/soft wrap in the editor while typing is easy but not enough, a
mapping between the model lines and the visual lines must be introduced to e.g.
correctly show annotations. It also introduces various problems that need to be
solved, e.g. 'Go to Line': tools like a debugger, compiler etc. will report the
model line but a user it will look strange that a different line will be
selected than the one entered into the 'Go to Line' dialog i.e. the dialog will
probably have to support both, model and visual line numbers.

Having said that, I will add this one as an investigation item to the 3.2 plan.
Comment 12 MD CLA 2005-05-18 21:16:07 EDT
(In reply to comment #11)
Just my 2 cents regarding comment #11, if I understood it correctly.  The Emacs 
method of line numbering may be a good solution.  Only model line numbers are 
shown in the editor, and not display line numbers.  A "wrapped-line 
continuation marker" is shown at the end of every wrapped line portion.  'Go to 
line' takes you to the beginning of the model line number in the editor.  
Showing visual line number depends on the size of the display window, and seems 
less useful than showing model line number.
Comment 13 Christian Pekeler CLA 2005-05-19 00:01:43 EDT
I like how Apple's IDE Xcode handles line wrapping. In fact, it represents the behavior that I expect from 
any other application on the mac. For those not familiar with Xcode, here's a little screenshot of line 
wrapping in action: http://pekeler.org/XcodeLineBreak.png
Comment 14 Dani Megert CLA 2005-06-01 05:24:55 EDT
*** Bug 97767 has been marked as a duplicate of this bug. ***
Comment 15 Dani Megert CLA 2005-09-08 04:29:30 EDT
*** Bug 109034 has been marked as a duplicate of this bug. ***
Comment 16 Aaron Digulla CLA 2005-12-21 03:55:33 EST
You might also want to look at jedit.

It has two wrap modes: Soft and hard. Soft will just warp the text at the right window border without adding new line numbers (so there are gaps in the list of numbers when you enable them).

This mode is useful for HTML and the like.

Hard will add and remove newlines in the text as you type to balance the width. Here, you can usually set a margin (80 characters, for example). This is useful for READMEs and other stuff that will be read in a terminal.

A nice feature of the soft wrap is automatic indentation: If there is whitespace at the beginning of the line, the wrapped lines are automatically indented by the same amount.
Comment 17 Ed Burnette CLA 2005-12-22 15:06:23 EST
I can't speak for anybody else but "soft wrap" is what I'm looking for. To do hard wrap we always have the reformat command. I've never used an editor that did the auto-indent with soft wrap so I don't have a preference one way or the other on that.
Comment 18 Eric Raymond CLA 2005-12-22 18:12:54 EST
Soft wrap is what I want.  Indentation might be nice, but I'd rather not complicate the implementation by having it indent (and it will never do it 100% correctly across all types of editor windows in them inds of all users).
Comment 19 Matt Chaput CLA 2006-01-06 18:53:18 EST
(In reply to comment #18)
> Soft wrap is what I want.  Indentation might be nice, but I'd rather not
> complicate the implementation by having it indent (and it will never do it 100%
> correctly across all types of editor windows in them inds of all users).

Indentation of soft-wrap is a high-priority feature for me. Editing structured text/HTML/XML without it is very annoying, because except for the first line nothing is indented, so the structure is barely visible. And it looks unpleasant.

I'm not sure what could be done "incorrectly"... you just indent subsequent (soft-wrapped display) lines the same amount as the initial (model) line. Don't bother trying to do anything fancy like auto-indenting spillover arguments in a Java call differently or anything like that.
Comment 20 Dani Megert CLA 2006-01-18 04:52:42 EST
Sorry, but this won't make it into 3.2.
Comment 21 Eric J. Schwarzenbach CLA 2006-01-18 11:02:01 EST
The annoying thing about this is that it is such a basic feature. Anyone switching from another text editor is going to miss it, because they all have it. Even Windows Notepad has it! Don't we find it a little embarrasing that we don't? It seems to me that completeness of basic text editor features should have priority over the hosts of more advanced features that are getting worked on.
Comment 22 Aaron Digulla CLA 2006-01-18 14:46:25 EST
Can we have a menu toggle item which just toggles the wrap property of the text editor for 3.2, please?

For someone who knows the Eclipse editor source, this should take five minutes or less.
Comment 23 Channing Walton CLA 2006-01-19 01:07:02 EST
(In reply to comment #22)
> Can we have a menu toggle item which just toggles the wrap property of the text
> editor for 3.2, please?
> 

I did this in my editor but there is a problem with it - see bug Bug 47280 (Current line highlight is incorrect for wrapped lines). Both these bugs need to be addressed really.
Comment 24 David M. Karr CLA 2006-03-02 12:50:06 EST
(In reply to comment #18)
> Soft wrap is what I want.  Indentation might be nice, but I'd rather not
> complicate the implementation by having it indent (and it will never do it 100%
> correctly across all types of editor windows in them inds of all users).

Interesting.  I don't really care if soft wrap is implemented.  I want hard wrap as I type.  When you're writing code, you want manual newlines.  When you're writing documentation in comments, you want it to work like a text editor, where it adds newlines around the print margin (along with the comment prefixes).

Eclipse still hasn't caught up to Emacs in this area.
Comment 25 Eric Raymond CLA 2006-03-02 13:04:15 EST
I feel quite the opposite.  I hate it when an editor adds hard line breaks.  I almost always spend my time fighting with the editor over "style".   The editor can modify the view, not the model.

Given that Eclipse is use to edit a variety of languages, getting hard line wrapping to work well in all modes and user styles (and for plugins) will be a challenge.

Since soft wrapping is non-destructive, the bar may be lower....
Comment 26 Dani Megert CLA 2006-04-07 04:11:28 EDT
*** Bug 49776 has been marked as a duplicate of this bug. ***
Comment 27 Rob Reno CLA 2006-04-20 14:16:09 EDT
Word wrap toggle button does not show current state of word wrapping.  If you click on word wrap in a document once.. the button shows correct.  When you open another document, it does not reset to show the upwrapped state.  When you click the toggle button in the new document it shows the button in the unwrapped state... even though it is wrapped.  When you go back in to the previous document the button does not show the corrent state anymore.
Comment 28 Aaron Digulla CLA 2006-05-08 09:28:53 EDT
I'm on Eclipse 3.2RC3 but I can't find the word wrap toggle button. Where is it?
Comment 29 Dani Megert CLA 2006-05-08 09:32:26 EDT
>I'm on Eclipse 3.2RC3 but I can't find the word wrap toggle button. Where is
>it?
There's no such thing for the text and Java editor.
Comment 30 Philippe Ombredanne CLA 2006-05-28 08:22:54 EDT
Ahti Kitsik has submitted a proposal for the Google Summer of Code program to provide help with this bug, and it was accepted!
All the support he can get is welcomed.
Comment 31 Ahti Kitsik CLA 2006-05-28 08:58:19 EDT
Thanks for the introduction, Philippe!

As this task might become pretty complicated I'll call up everyone to see if he/she has toughts or ideas that are not yet written into this item comments.

Decisions about wether the setting should be shared or customized for each opened file and what kind of formattings to apply (to keep smooth indentation) etc are probably not yet relevant and are relatively easy to implement.

My biggest concern is currently viewer and editor structure to support this feature in an elegant way. Will continue to digg code.

Thanks again!
Comment 32 Mark A. Ziesemer CLA 2006-05-28 12:13:54 EDT
Please see also bug 100315.  (Not yet directly listed within these comments; contains another example image for reference.  (Duplicated through bug 23579.))  Thanks!
Comment 33 Tom Hofmann CLA 2006-05-29 03:09:26 EDT
(In reply to comment #31)
> As this task might become pretty complicated I'll call up everyone to see if
> he/she has toughts or ideas that are not yet written into this item comments.

Interesting dimensions for soft-wrapping (no need for everyone on the CC list to state their preference for each item):

- how much of the model line structure to show to the user:
  - line numbers (do wrapped lines get a line number?)
  - navigation (does ARROW_DOWN take you to the next model line (vim), or to
    the closest caret location on the next visual line (notepad)? similar for
    END.)

- find all places where code implicitely assumes no line wrapping 
  - painting
  - projection (aka. folding)
  - ruler painting
  - viewport management (e.g. revealing a text location)

- UI
  - how to indicate to the user that a line is wrapped (not common in text
    editors, but more so for code editors)
Comment 34 Dani Megert CLA 2006-05-29 08:33:47 EDT
Note that when adding this, existing clients cannot be broken (i.e. API compatibility must be guaranteed).

Another concern is performance: the performance must not degrade in the case of disabled word wrap and be acceptable for large files if enabled since this feature affects the typing speed.
Comment 35 Aaron Digulla CLA 2006-05-29 15:46:43 EDT
In jEdit, you have these features:

- Wrapped lines get a single line number

- The cursor doesn't jump around ie. notepad-mode; vi is broken in this regard. Just imagine a line with several thousand characters! That's impossible to edit in vi.

- Every fifth line on the screen has a highlighted line number. This is not affected by word wrap (ie. if line 20 wraps into four lines, then both 20 and 21 are highlighted).

- If the first character of the line is indented, all wrapped lines are indented as well. You cannot move the cursor into the space before the wrapped lines but it's not highlighted when you select the whole block.

This is to avoid this confusion:

      first words ....
wrapped around
      second line ....
more wrapped text of second line

ie. the wrapped text suddenly disturbs the read flow.

Note: This bug report is *not* about reformat/reflow text (ie. change the places where linefeeds are) but about the visual representation without modifying the model. Maybe there should be another bug for reformatting text.
Comment 36 Edward A Savage Jr CLA 2006-06-11 11:20:25 EDT
I'm all for the soft wrapping.  The intelligent indent of wrapped lines would be neat, but since I would normally set the wrapping to off, and only have turn it on for a specific line, it's not as big of a value for me.  I can also see the value of hard wrapping, though I don't think I'd ever use it.  My biggest concern is that the feature be added to the basic text editor for Eclipse and that it will automatically extend to the subsequent plugin editors (I use CFEclipse, PHPEclipse, the SQL editor, etc.).

Doing a quick Google search gave me this hit:
http://texlipse.sourceforge.net/manual/wrapping.html
It's a Latex editor plugin for Eclipse.  I has an implementation of both soft and hard wrapping.  You may be able to use this as a base for designing the Eclipse standard one.
Comment 37 Aaron Digulla CLA 2006-07-04 07:12:56 EDT
Re Comment #31: Athi, I saw that you put up a web page which contains first draft of your code. Can you please post the link here?

Also, when you do the necessary changes, can you please also have a look at http://nickgravgaard.com/elastictabstops/ and see if your work could be used to implement something like that?

These changes could then become the basis to work on bug 45423 (Seperate source presentation from formatting).
Comment 38 Hendrik Maryns CLA 2006-07-04 07:33:48 EDT
(In reply to comment #37)
> Re Comment #31: Athi, I saw that you put up a web page which contains first
> draft of your code. Can you please post the link here?
> 
> Also, when you do the necessary changes, can you please also have a look at
> http://nickgravgaard.com/elastictabstops/ and see if your work could be used to
> implement something like that?

Only if it is an option which can be switched on and off.  E.g. this will not work for lisp-code indented the traditional way (though probably no lispers use Eclipse).
Comment 39 Edward A Savage Jr CLA 2006-07-04 07:42:48 EDT
(In reply to comment #37)
That is awesome, and is quite a paradigm shift.  Maybe the entire word wrap feature should be optional this part of it would not be, "forcing" adoption of a better method!  I don't know anything about lisp, so it seems really strange to me that this would break code.
> http://nickgravgaard.com/elastictabstops/
Comment 40 Hendrik Maryns CLA 2006-07-04 07:59:20 EDT
(In reply to comment #39)
> (In reply to comment #37)
> That is awesome, and is quite a paradigm shift.  Maybe the entire word wrap
> feature should be optional this part of it would not be, "forcing" adoption of
> a better method!  I don't know anything about lisp, so it seems really strange
> to me that this would break code.

It wouldn’t break code, of course, but there are rather strict indentation rules, which say that lines should start exactly under some other argument to a function and stuff.  Thus a typical piece of lisp looks like this:

(defmethod new-marked ((transitions list) marked)
  (do ((transitions transitions (cdr transitions))
       (tomark '()))
      ((endp transitions) tomark)
    (when (has-only-marked-states (left-handside (first transitions)) marked)
      (setf tomark
	    (state-adjoin (right-handside (first transitions)) tomark)))))

Notice how (tomark lines up with the second parenthesis above, whereas the next line lines up with the first etc.  I don’t see lispers to abandon that style, so the elastic tabs should be optional.  (But then again: there is only one, very incomplete, plugin for writing lisp in Eclipse.)
Comment 41 Aaron Digulla CLA 2006-07-04 15:03:53 EDT
Currently, I just want the word-wrap code to be built in a way to support this.

It must become a basic feature of the text UI element which every editor and/or user can turn on and off as necessary.

Examples: In Python, you must always indent. There, it would even make sense to move the left border of the editor (so no moving into the space in front of the current line).

Java might benefit from this if we can find a way to keep editor lines and line numbers in exceptions in sync.

Lisp would be easier to indent in the editor view; Eclipse could automatically export the code with the correct number of spaces even if you were using a proportinal font.

The goal should be: Don't bother the user with wasting their time to format the source. Code should always look its best and the user should be free to concentrate on content.
Comment 42 Dani Megert CLA 2006-07-06 08:31:59 EDT
Please see bug 149603 for elastic tab stop discussions and move them there. This bug is about word wrap support which is rather independent from an elastic tab stop feature and in addition requires not yet available SWT support.
Comment 43 Aaron Digulla CLA 2006-07-06 15:10:53 EDT
> This bug is about word wrap support

True, but while this bug here gets fixed, it would be nice to have an eye on allowing to extend the code to allow elastic tabs, too.

Just to avoid to have to write everything again just because we notice that the solution for this bug prevents implementing elastic tabs.
Comment 44 Andrey Loskutov CLA 2006-10-14 17:22:42 EDT
Is there any chance to see the progress on this bug for 3.3? 
The bug is very old, has many votes, and almost every editor today (except Eclipse) could soft wrap lines, even notepad could do it (no, I do not use notepad :)

I really hate to switch to JEdit each time I work with lines longer then 120 chars, only because Eclipse could not handle soft wrap...

Please please, include this one to the plan for 3.3!
Comment 45 Dani Megert CLA 2006-10-16 03:36:54 EDT
Sorry, but this won't make it into 3.3.
Comment 46 Edward A Savage Jr CLA 2006-10-16 08:52:52 EDT
(In reply to comment #45)
> Sorry, but this won't make it into 3.3.
> 
Not to be rude, but that's a pretty lousy reply.  This is something that has been added to many plugins that really should be in the core product.  I can't personally think of any other text editor that does not support this.  Could we at least get a reason, not just a "not this time"?
Comment 47 Dani Megert CLA 2006-10-16 09:17:17 EDT
It is hard to add this feature so that all existing features still correctly work and it will also be tricky to do this in a performant way.

We do not have the resources to work on this for 3.3.
Comment 48 Eric J. Schwarzenbach CLA 2006-10-16 09:41:38 EDT
I don't suppose it could be given priority over other features, as an embarrassing design omission of a REALLY REALLY  basic text editor feature?

I don't mean to be obnoxious, but it feels to me like "putting doorknobs on the doors will be hard to fit in because there's so many doors, and we're really busy putting pool tables in the game room, and rotating shelves in the library, and auto-darkening windows." (Please take that in the humerous spirit it was written...)
Comment 49 Christian Pekeler CLA 2006-10-16 10:06:31 EDT
> To be investigated after 3.0
> I will add this one as an investigation item to the 3.2 plan.
> Sorry, but this won't make it into 3.2.
> Sorry, but this won't make it into 3.3.

Wow!
:-(
Comment 50 Aaron Digulla CLA 2006-10-16 14:46:05 EDT
I guess this means someone (hint,hint) should have a look how hard it would be to create a jEdit plugin for Eclipse :-)

The problem with the current text editor implementation is that it's not so simple to extend the rendering because this code is spread all over the place and somewhat coupled with the model, etc., so changes give a headache. Maybe a fresh start with a cleaned copy from jEdit or another good Java Text editor might improve the situation.
Comment 51 Marko Schulz CLA 2006-10-16 15:18:05 EDT
A little pointer for the really desperate: In Googles summer of code this year Ahti Kitsik worked on a soft word wrap plugin. He released a version 0.0.2. The number shows that the plugin may eat baby seals, but some may give it a try. 

The plugin is available from his update site (http://ahtik.com/eclipse-update/) and he blogged about it with the category "eclipse" (http://ahtik.com/blog/category/eclipse/).
Comment 52 Dani Megert CLA 2006-10-17 02:50:38 EDT
Ahti, maybe you can also provide a pointer to the final work you did for the Google SOC 2006 project - I couldn't find it.
Comment 53 Ed Burnette CLA 2006-10-17 14:15:43 EDT
There are a few entries like this one (scripting comes to mind, see bug 8519 and friends) that get looked at every year but never make it into a plan due to lack of time or resources. Maybe we should be trying to get them on the 3.4/4.0 plan (2008 version, "Io") instead? That way we won't be having this same discussion next year, and the year after that, and, ...
Comment 54 Eric Raymond CLA 2006-10-17 14:19:57 EDT
Corect me if I'm wrong, but I beleive the Google SOC 2006 more/less just enabled the wordwrap feature in the SWT component used in the editor's view.  It did not address the issues associated with the effects of soft wraps on things which care about absolute and relative position of lines on the page (e.g., line numbering).
Comment 55 Andrey Loskutov CLA 2006-10-17 14:39:23 EDT
to comment 53: sorry, it starts to be a bit offtopic, but what we can do to *get it really in* the next release plan? 

Who is responsible and/or capable to do it? Should we open a "top 10 bugs for the next release" bug which at the end would collect top 10 of "really really must have since 1.0" bugs for 3.4 before it's again too late? As Eric in comment 48 said, who needs the "pool tables in the game room" if there "no doorknobs on the doors" in the next release?

Or is there any possibility to have a dedicated web page on eclipse.org where *the community* could see and vote what *must* be in from the top 10 bugs on plattform? Of course no one would be able to implement all the wishes, but again - top 10 would be ok for the first time.

So any other proposals how to get this bugs first on the project plan and then fixed?
Comment 56 Eric Raymond CLA 2006-10-17 17:11:27 EDT
Get more votes for the bug?  I'm not sure if the Eclipse team uses votes to prioritize bugs.

It certainly seems like this is a fairly involved task so it requires some "act of governance" rather good intentions on the part of a few.
Comment 57 Aleks Totic CLA 2006-10-17 17:33:02 EDT
Another vote of sympathy for the Eclipse team. It seems that this feature cuts deep, and can't be implemented trivially. That design of class hierarchy to make soft-wrap is something I'd probably steam about, but right now, you've got to work with the code base you have.
Comment 58 Ahti Kitsik CLA 2006-10-18 12:57:24 EDT
My current knowledge is that neither intellij idea nor netbeans has support for soft word wrap.

IDEA: http://www.jetbrains.net/jira/browse/IDEABKL-1132
Netbeans: http://www.netbeans.org/issues/show_bug.cgi?id=33419

Still. There is no reason why eclipse couldn't have this :)

I tried to implement this at this summer (google summer of code 2006) but unfortunately current eclipse text editor architecture was not too supportive.

A few notes on the issue that should be solved to get this thing fixed.
I would say this problem is the most critical in eclipse text editor as I don't know ANYONE who does not want that.

MIGRATION PROBLEMS
Many eclipse and 3rd party plugins needs to be updated after line model is broken into two separate line models (soft and hard line model).
For example line number ruler column needs both models: soft for ruler column number positioning and hard for actual numbers.

For transition period it does not seem to be reasonable to show everyone soft line model as it can seriously damage underlying code.
Using hard wrap for transition period model would break many visual gadgets.
Maybe someone has a good idea to overcome this?

SOC 2006 IMPLEMENTATION
Main usable code is the same plugin that Eric Raymond mentioned:
It turns SWT soft wrap on and off. It is breaking line numbering and causes other expected/unexpected visual damages.

IMPLEMENTING DUALMODE LINE MODEL
Implementation notes that were produced along the development (incl. evaluation notes about storing hard and soft line model in parallel):
http://wiki.eclipse.org/index.php/Word_Wrap_for_Text_Viewer_and_Editor

The best place to implement this dualmode line model seems to be ILineTracker used by AbstractDocument().getTracker().
All components (including StyledText) reference this to get line information.

Tracker can also handle different kind of linebreaks.
That's why eclipse text viewers doesn't care if it's \n or \n\r and preserve used linebreak symbols :)

** Implementing dualmode line model at ILineTracker **
Design issues:
1) ILineTracker implementation in AbstractDocument is TreeLineTracker.
It uses binary tree structure to hold information about lines, line length, offsets and delimiters. TreeLineTracker itself does not hold anything else than line length and delimiter (and offset etc).
ILineTracker model can be modified with ILineTracker.replace(int offset, int length, String text).
Problem: Replace should be able to detect spaces between words etc to properly wrap. This is impossible without knowledge about existing text. Keeping text in linetracker would be enormous performance factor!
2) TreeLineTracker needs heavy redesign to support 0-length line delimiters (soft linebreaks) and provide two line models in parallel.
I started to implement TreeLineTracker changes but but time was running out after getting so far :( Continuing now without real achievable roadmap for getting this into core seems also a bit useless.

CONCLUSIONS
I think that current architecture makes soft wrap pretty time-consuming task to implement and requires serious planning and coordination. Possibly more than one developer was capable of finishing with one summer :=)

Someone could still port jedit as an eclipse plugin (without swing bridge!!).

I hope it shed some light on word wrap issue :)
Comment 59 Yaron Mazor CLA 2006-12-24 09:05:45 EST
*** Bug 163761 has been marked as a duplicate of this bug. ***
Comment 60 Mike Haller CLA 2006-12-25 08:55:55 EST
Is there any reason why this can't be just added to the plain text editor?
I don't really see the benefit to have soft wrap in complex text editors like the Java Editor. And if this is so difficult to implement, why not limit the feature to the plain text editor?

It's a pain to see Eclipse missing such basic features. I wouldn't care if there is another type of text editor, which provides word wrap but lacks some of the features conflicting with word wrap.
Comment 61 Kai Grabfelder CLA 2006-12-25 09:14:14 EST
You are right, User that are coming from other IDEs allways laught at me when I have to tell them that there is no word wrap. So please consider fixiging this issues...



(In reply to comment #60)

> It's a pain to see Eclipse missing such basic features. I wouldn't care if
> there is another type of text editor, which provides word wrap but lacks some
> of the features conflicting with word wrap.
> 

Comment 62 David M. Karr CLA 2006-12-25 12:58:15 EST
(In reply to comment #60)
> Is there any reason why this can't be just added to the plain text editor?
> I don't really see the benefit to have soft wrap in complex text editors like
> the Java Editor. And if this is so difficult to implement, why not limit the
> feature to the plain text editor?

One of the things I miss from my old Emacs editor is the ability to type Java comments (both kinds) and have it automatically insert a newline at the word wrap boundary, indent to the current indent level, add the comment prefix, a space, and then the portion of the word that caused the word wrap.  It will also rejustify comment blocks (on command) after inserting or deleting text from comment blocks.  This set of features is available for numerous language editors in Emacs, using different comment syntaxes.
Comment 63 Jean-Marc N/A CLA 2007-04-02 19:27:10 EDT
(In reply to comment #16)
> This mode is useful for HTML and the like.

I agree as HTML documents usually contain stuff like DOCTYPE definition, meta keywords, long sentences in paragraphs... As of version 3.2.2 it seems the wrapping feature is only available for Java sources and accessible from the "Java > Editor > Typing" section of the preferences dialog.
Comment 64 Jean-Marc N/A CLA 2007-04-02 19:40:46 EDT
(In reply to comment #50)
> The problem with the current text editor implementation is that it's not so
> simple to extend the rendering because this code is spread all over the place
> and somewhat coupled with the model, etc., so changes give a headache. Maybe a
> fresh start with a cleaned copy from jEdit or another good Java Text editor
> might improve the situation.

Does it mean Eclipse can't be extended and customized as easily as Firefox can be ? Firefox UI is based on XUL and every single elements can be quickly "tweaked" using simple JavaScript code or developing extensions. Such a powerful and flexible architecture would make Eclipse far much easier to maintain and improve. For example as a temporary solution, a "Line wrapping" extension could be used to add a "Wrap line" checkbox to the "General > Editors > Text Editors" preferences and implement the feature to override the default behaviors of the text editor implementation. Eclipse developers could then later decide if the extension worth being included to a release. It's what happened to some session management (tabs restoration feature...) extensions when Firefox 2 was released. The community develops extensions and the most useful ones are released with the product. It makes the releasing process far much efficient, and accessible to developers, as users don't have to wait for like 4 years to get basic features.

As a developer I feel like Eclipse is not as opened as it should be. I'm probably wrong but it seems its architecture is not as well-designed, simple and accessible as Firefox one is. Note that it's only what I feel, I don't know much about extending Eclipse to get the IDE I need. I read a few tutorials about developing plugins and found the approach a bit scary. I really dig Firefox architecture and extension development, simple and powerful. Don't hesitate to reference some cool tutorials to help me better understand Eclipse and prove me wrong.
Comment 65 Wolfgang Lorenz CLA 2007-04-20 08:06:16 EDT
Created attachment 64418 [details]
Kate style of line wrapping

Using Eclipse for programming C++ I never missed this feature up to now. (I didn't even realise it was missing :-) ). But lately I also tried out LaTeX for Eclipse and found out, that this has to bring it's own line wrapping functionality. I think it doesn't sound good for an all-round development tool like Eclipse to miss a basic function like this one. Working with KDE I think Kate has a really good style of line wrapping (see attachment). I hope an implementation comes soon - or at least: as soon as possible...
Comment 66 Dani Megert CLA 2007-08-24 09:24:58 EDT
*** Bug 36589 has been marked as a duplicate of this bug. ***
Comment 67 Nils Kilden-Pedersen CLA 2007-12-04 11:11:11 EST
Any plans for 3.4?
Comment 68 Dani Megert CLA 2007-12-04 11:35:47 EST
No.
Comment 69 Jean-Noel Rivasseau CLA 2008-03-26 06:33:05 EDT
Ok, so despite 78 votes for this bug (which probably makes it one of the top voted for Eclipse bug, if not the first), this was not scheduled for 3.2, for 3.3 and now not for 3.4...

Has it any chances of finally being implemented or not? Even for Eclipse 3.5 or 4.0 ...
Comment 70 Francis Labrie CLA 2008-03-26 07:53:10 EDT
Yes, it's a real shame a such basic functionality isn't yet supported, nor planned soon. All standard text editors and concurrent IDE support this. Please, wake up Eclipse team and plan to support word wrap ASAP.
Comment 71 Alex Blewitt CLA 2008-03-26 11:17:56 EDT
This is already too late for 3.4. I'd imagine we'll be having exactly the same debate by the time 3.5 comes around, though. Maybe someone with suitable rights could change the  Version field to a bit more recent value though?
Comment 72 Aaron Digulla CLA 2008-03-26 15:02:57 EDT
There are two problems with this bug:

a) There is no real demand. Sure, a lot of people voted for it (I did) but there are many other editors out there which have proper word wrap, so it's not a real blocker.

b) The current code doesn't support word wrap. So adding this feature looks more like a complete rewrite of one of the most complex classes in SWT.

Therefore: As long as no one with a few months of time at her/his hands steps up to work on this (there was a GSoC project but AFAIK, the code was never published anywhere), it won't happen. Sad but true.
Comment 73 Jean-Noel Rivasseau CLA 2008-03-26 15:09:15 EDT
I *strongly* disagree. There is a real demand and lots of people are surprised that Eclipse does not do such a simple thing. Yes there are other editors out there that have this feature, so what?? I still prefer Eclipse because it beats all other editors in many areas, but this is really the improvement I would like to see in Eclipse.

As for the complexity of word wrapping, I understand that this may be very difficult to implement. The GSoC project you mentionned lead however to a published plugin, that is somewhat usable, but lots of work still needs to be done. Sure it's hard, but feasible, and if the only new improvement in 3.5 was proper word wrapping, I would still be more happy than with a tons of other features but no word-wrapping.

No word-wrapping = really hurts productivity, at least for me.

> There are two problems with this bug:
> 
> a) There is no real demand. Sure, a lot of people voted for it (I did) but
> there are many other editors out there which have proper word wrap, so it's not
> a real blocker.
> 
> b) The current code doesn't support word wrap. So adding this feature looks
> more like a complete rewrite of one of the most complex classes in SWT.
> 
> Therefore: As long as no one with a few months of time at her/his hands steps
> up to work on this (there was a GSoC project but AFAIK, the code was never
> published anywhere), it won't happen. Sad but true.
> 

Comment 74 Francis Labrie CLA 2008-03-26 15:44:29 EDT
+1 
It also hurts our productivity in our company: Eclipse it's a complete and integrated IDE. Why should developers use another text editor just to be able to see long line of code, text, definition, etc. without having to scroll right and left all the time? This is a nonsense: there is real demand for word wrap, trust me.
Comment 75 Ahti Kitsik CLA 2008-03-26 15:53:35 EDT
Implementation complexity is not the only issue here.

After Physical and Visual line numbers become different, quite a lot of plugins break down. As a fallback, default Physical line could be returned but that means all visual things like markers, folding etc break down.

The only we it can possibly work is when API adds support to both Physical and Visual line numbers and for now no wrapping is enabled.

After some period when eclipse.org and other plugin developers have had time to adopt new API, wrapping implementation can be put in place and put fingers crossed.

Going from singleLineInfo to physical&visual-line-info can be tricky for some plugins requiring possibly quite considerable rewrite.

Eclipse Platform can do physical/visual separation API and all the line wrapping implementation at once but then it is too aggressive for 3rd party plugin developers IMHO.

Now, when starting to put in place the API for this - there is an additional feature to consider - invisible characters. So visual line wrapping would respect tabs (and being configurable for this) - IMHO it's important to think about this right away! Makes API a bit more complex but definitely worth it.

I wonder if Eclipse team platform agrees to these ideas and problems I mentioned above. Plus it's interesting to know if this is the kind of risk they are willing to take (for example breaking the api and introducing API before the implementation).
Comment 76 Nils Kilden-Pedersen CLA 2008-03-26 16:24:06 EDT
API compatibility is a very valid point, which is why this will probably never make it on 3.x.
However there seems to be no reason nor excuse to not include this in 4.0, whenever that may be.
Comment 77 Aaron Digulla CLA 2008-03-26 17:53:48 EDT
(In reply to comment #74)
> +1 
> It also hurts our productivity in our company:

It hurts me, too. But let's face it: It's not a killer. You have an easy work-around.

If Eclipse was completely unusable because of the lack of this feature, there would be no discussion and we'd have had word wrap in 3.0.0 or maybe even in 2.1.1.

That's why I don't think we'll see this feature in the next two or three years: Too expensive (it would swallow a lot of resources from the Eclipse developers) at too little revenue. It's like having to decide whether we'll have 100 bugs fixed in 3.5 or 100 new features implemented or have this single one fixed. It's easy to see why nothing has happened in the last four years.

I believe that this feature will only ever see the light of day when someone dedicated (and probably outside the Eclipse foundation) writes a completely new Editor API. Yeah, it sucks but there are only 24h in a day.

(In reply to comment #75)
> Implementation complexity is not the only issue here.
> After Physical and Visual line numbers become different, quite a lot of
> plugins break down.

I counted that under implementation complexity. As I see it, word wrap is implemented when the API is stable and all plugins work again. I mean, there is little point in having word wrap when Eclipse crashes the instant you turn it on :)
Comment 78 Matěj Cepl CLA 2008-03-26 18:32:37 EDT
(In reply to comment #77)
> It hurts me, too. But let's face it: It's not a killer. You have an easy
> work-around.

Like? Aside from using another text editor (which is tempting ;-)) I don't know about any.

Given that there is an opportunity for Eclipse to really shine as a XML authoring tool, I would really think that this shouldn't be dragged behind as unwanted orphan from release to release.
Comment 79 Jean-Noel Rivasseau CLA 2008-03-26 19:04:12 EDT
As I already said, I for one would prefer this single one fixed instead of 100 new features... But I agree it's unfortunately very expensive. I, however, think each passing day / new plugin developed will add to the complexity of coming up with a new clean API that does this.

I mean, if stuff needs to be broken at a low level, let's do it as soon as possible, before it's downright impossible.

> That's why I don't think we'll see this feature in the next two or three years:
> Too expensive (it would swallow a lot of resources from the Eclipse developers)
> at too little revenue. It's like having to decide whether we'll have 100 bugs
> fixed in 3.5 or 100 new features implemented or have this single one fixed.
> It's easy to see why nothing has happened in the last four years.
>
Comment 80 MSO CLA 2008-04-04 12:50:00 EDT
hey guys, before we get all carried away and think about designing superior word wrap functionality could we not just plan simple, basic minimal word wrap functionality and then develop it more every release until we finally have a satisfactory solution.

start small, and later we can build on that. that's the way it should be so that it doesn't take up too much resources and at least some basic word wrapping is available.

if people don't like the basic functionality (e.g. it's a bit buggy or line numbers are incorrect), then they are free to turn it off. as simple as that. but what is overlooked here is most people don't really care about that "extra" stuff and just want to be able to see all code without scrolling horizontally every now and then and then they can turn it off.

so, can we get some basic word wrap functionality please.
Comment 81 Eric J. Schwarzenbach CLA 2008-04-04 14:50:36 EDT
(In reply to comment #80)

I hope no one on the Eclipse team considers correctness and non-bugginess to be "extra stuff" or not a part of "basic functionality". 

> hey guys, before we get all carried away and think about designing superior
> word wrap functionality could we not just plan simple, basic minimal word wrap
> functionality and then develop it more every release until we finally have a
> satisfactory solution.
> 
> start small, and later we can build on that. that's the way it should be so
> that it doesn't take up too much resources and at least some basic word
> wrapping is available.
> 
> if people don't like the basic functionality (e.g. it's a bit buggy or line
> numbers are incorrect), then they are free to turn it off. as simple as that.
> but what is overlooked here is most people don't really care about that "extra"
> stuff and just want to be able to see all code without scrolling horizontally
> every now and then and then they can turn it off.
> 
> so, can we get some basic word wrap functionality please.
> 

Comment 82 MSO CLA 2008-04-07 05:31:46 EDT
ok, so it's back to square one. we're not getting any word wrap. correctness is subjective and "non-bugginess" depends on people's ideas of what is correct so if you've worked in largescale software development you will know that you can never have either. also if you've read this thread from the start you might have realised it too, as everyone is asking for something different. i guess we won't be settling for basic door knobs then.
Comment 83 Eric J. Schwarzenbach CLA 2008-04-07 10:38:28 EDT
(In reply to comment #82)

No, correctness and non-bugginess are not subjective, and yes I have worked in large-scale software development for many years. You can, and always should, have correctness, and relative  non-bugginess. Correctness is defined by a spec, of "this is how this features is supposed to work." Now specs of course may be good or bad according to subjective judgment, and the process of arriving at the spec can be contentious, though with rigorous domain analysis and modeling, one may reject many bad designs and find one that most people will agree on. This process is one of the more challenging areas of software development, but the problem of coming up with a good spec is rarely a problem of some subjective disagreement, but poor communication, lack of clear and agreed on terminology, muddy thinking, etc. 

But none of this has much to do with this issue. I don't think what people are asking for is so very disparate. The problem has clearly been identified that the design of the underpinning system does not support line wrap (I would call it a design flaw, but that may be subjective). Any fix which does not address this underlying design problem is going to be a hack, and will almost certainly be buggy and incorrect. Addressing the underlying design issue is going to be costly.

(My apologies for following this tangent, but I couldn't let those comments stand.) 



Comment 84 MSO CLA 2008-04-07 11:09:00 EDT
Ok, agreed. Maybe my comments were a bit too broad and I should have been more specific and said they "can in some cases" be subjective such as in the case of this issue. In many cases where the gain is compared against the effort a hack is acceptable and I am saying that this may be one of those cases. Emphasising that the underlying design is flawed and needs to be redesigned just means that, realistically, this issue will not be worth the effort and will not be implemented.
Comment 85 Aaron Digulla CLA 2008-04-18 04:55:16 EDT
Please add "helpwanted" as a keyword for this bug since the Eclipse committers are not committed to this bug :)
Comment 86 Tev Kaber CLA 2008-07-29 16:53:16 EDT
As a user new to Eclipse, I was appalled that there is no soft text wrap.
I have NEVER used an IDE or text editor before that did not have it!

Eclipse seems to have some cool features, but the lack of soft text wrap has soured my first impressions of it.  It makes it seem unprofessional.  The fact that users have been clamoring for the feature for years but have been ignored says to me that user support isn't a priority for the Eclipse dev team.

This may be unfair, this is just my initial impression (soft text wrap is very important to me, and the first option I turn on when using a new editor).

 Zend just discontinued the stand-alone Zend Studio and converted it to a plugin for Eclipse, so Eclipse is now the editor I'll have to use.   For now I'll just have to write my code using lots of hard returns, so I don't have to constantly scroll left-to-right.

I realize that soft text wrap was an early oversight that is difficult to correct now, but it's a very basic and useful feature, and it would be a much appreciated addition.
Comment 87 Gary Gregory CLA 2008-07-29 17:54:14 EDT
WRT "For now I'll just have to write my code using lots of hard returns, so I don't have to constantly scroll left-to-right."

Or you can set the line width to your favorite and every you format the code (Ctrl-Shift-F), you'll get that done for you.

If you experiment with the formatter, you'll find it highly customizable and flexible.
Comment 88 Jean-Noel Rivasseau CLA 2008-07-30 03:23:52 EDT
(In reply to comment #87)
> WRT "For now I'll just have to write my code using lots of hard returns, so I
> don't have to constantly scroll left-to-right."
> 
> Or you can set the line width to your favorite and every you format the code
> (Ctrl-Shift-F), you'll get that done for you.
> 
> If you experiment with the formatter, you'll find it highly customizable and
> flexible.
> 

The formatter is excellent - the problem with soft wrap is that there is not a formatter for every language out there. If you use Eclipse only for Java the soft wrap problem is not too annoying because the Java formatter is excellent. But when you start doing XML, Groovy etc where the formatters are non existent or not as performant, you constantly wish there was soft wrap in Eclipse.

Now that 3.4 is released, can this be seriously considered for inclusion in 3.5? At least considered, not necessarily planned, but I wish there would be at least discussions going on from the core commiters / leads.
Comment 89 Dani Megert CLA 2008-07-30 06:46:22 EDT
>Now that 3.4 is released, can this be seriously considered for inclusion in
>3.5?
Sorry, but we won't work on this.
Comment 90 Francis Labrie CLA 2008-07-30 07:55:42 EDT
(In reply to comment #89)
> >Now that 3.4 is released, can this be seriously considered for inclusion in
> >3.5?
> Sorry, but we won't work on this.

And this is a shame. :-( 
It's a very bad idea to drop a such basic functionality which is very usefull, really. It's far from being a programmers whim.
Comment 91 Nils Kilden-Pedersen CLA 2008-07-30 08:02:37 EDT
> Sorry, but we won't work on this.

Why isn't this bug being closed then?
Comment 92 Gary Gregory CLA 2008-07-30 10:58:12 EDT
WRT "But when you start doing XML, Groovy etc where the formatters are non existent or not as performant,"

Why not fix these other editors then? IMO having a great formatter for any given language is better than a generic soft-wrap mechanism. At least, I'd rather have formatting...
Comment 93 Jean-Noel Rivasseau CLA 2008-07-30 11:10:19 EDT
(In reply to comment #92)
> WRT "But when you start doing XML, Groovy etc where the formatters are non
> existent or not as performant,"
> 
> Why not fix these other editors then? IMO having a great formatter for any
> given language is better than a generic soft-wrap mechanism. At least, I'd
> rather have formatting...

I agree that a formatter is better than soft-wrap, BUT on certain cases (like some XML files) it is just not possible: the text must remain exactly as it is, no modifications is allowed.

Also, there will *always* be plugins with no good implementations of a formatter. A feature like soft-wrap will benefit ALL of Eclipse. Too bad IBM cannot commit the resources to fix this.

WRT closing the bug, I think they leave it open in case a third party want to implement this (which makes sense - closing the bug would be the last thing to do). It also allows us to monitor when this bug will become the top-voted for in Eclipse :)


Comment 94 Chris Hubick CLA 2008-07-30 11:50:02 EDT
Formatters are not a replacement for soft wrap.

Similar to the design of HTML, wrapping should be left in the hands of the client displaying the document (soft wrap), not tied to a single arbitrary display standard (80 col hard wrap).  Soft wrap allows the editor to automatically display code in a fashion which is most appropriate for the screen on the system being used to view it, be it a 30" screen on a workstation or a 10" screen on a laptop.

Fitting more code on the screen can be a huge benefit to productivity, and without this feature I can't easily reformat code to suit my 30" screen as long as that code is being used by others and on systems without such a display.
Comment 95 Gary Gregory CLA 2008-07-30 14:19:09 EDT
WRT "I agree that a formatter is better than soft-wrap, BUT on certain cases(like some XML files) it is just not possible: the text must remain exactly as it is, no modifications is allowed."

Actually, some modifications make no difference from a canonical XML POV. For example, this:

<root a="abc" b="cfg" />

is equal to:

<root 
   a="abc" 
   b="cfg" />
Comment 96 Jeff CLA 2008-07-30 15:35:11 EDT
WRT "I agree that a formatter is better than soft-wrap, BUT on certain cases(like some XML files) it is just not possible: the text must remain exactly as it is, no modifications is allowed."

To expand on this, whether we are working on code or simply viewing it, applying a formatter is not a very feasible workaround.  

For the former case, it completely messes up the use of "diff"-like tools to see what changed between 2 versions (although I seem to recall reading recently about a diff-like tool that could deal with/ignore all types of formatting changes - breaking up a line into multiple lines, etc. -  but I don't remember what that tool is).  

For the latter case (simply viewing source code), I always have a *read-only* copy of files that I am not modifying, and while I now always checkout (e.g., lock) a writable copy of the file from CM before modifying, I know not all CM systems/approaches require locks, plus I rely on that whole read-only vs. writable local copy concept when refreshing my local workspace - that is, the CM "get" action detects writable local copies and prompts me before overwriting.  If I start making all local copies writable in order to be able to apply a formatter to the ones I'm simply viewing, that's going to make refreshing from the CM repository a nightmare at best and a disaster (overwriting my changes) at worst.
Comment 97 Nils Kilden-Pedersen CLA 2008-07-30 15:59:39 EDT
> but I don't remember what that tool is

That would be Eclipse :-)

Window -> Preferences -> General -> Compare/Patch -> Ignore white space, check.
Comment 98 Jeff CLA 2008-07-30 16:25:29 EDT
And that accounts for text broken across multiple lines?  Because the "diff" tool in my CM tool (PVCS Version Manager) has that same option ("Ignore white space"), but it doesn't seem to do much (not sure if it even ignores a line simply indented, but otherwise unchanged) and definitely does not ignore a line unchanged other than simply breaking it into 2 or more lines.
Comment 99 Lars Sonchocky-Helldorf CLA 2008-07-30 19:04:43 EDT
@Comment #97

> > but I don't remember what that tool is
> 
> That would be Eclipse :-)
> 
> Window -> Preferences -> General -> Compare/Patch -> Ignore white space, check.

All diff tools I am aware of - included the eclipse one with "Ignore white space" on - react very poorly when it comes to changes including line breaks. Add or removing line breaks almost always confuses the diff-algorithms severely. Also, checking in such reformatted code into SVN (or CVS if you're old fashioned) destroys the possibility to use the Team > Show Annotation functionality in a meaningful way (because said SCMs are also not clever about line break changes).

Please get over the reluctance to implement the word wrap feature. It's a standard feature in a lot of IDEs. I just want to mention https://bugs.eclipse.org/bugs/show_bug.cgi?id=8009 where after a long period of resistance there was finally some understanding for the problem in the hindsight (8009 is a Google Summer of Code project finally)
Comment 100 someone CLA 2008-09-07 16:55:31 EDT
Soft warp allways has its advantage since it can fit the code properly for any screen display size it just needs to have a proper procedure for it so it wont cut of words in the middle and only cut it in logical places (dosent the reformater offer this allready?)

Reformater hard warp might make the code look the same on all platform but it will probabley messup diff-tools and will not take advantage of your full screensize.
Comment 101 Mike CLA 2008-11-18 12:17:07 EST
Every other editor does this but eclipse.  

Comment 102 Jean-Noel Rivasseau CLA 2008-11-18 12:25:00 EST
Yes, and as pointed out in comment#100, this is an extremely useful feature if you are dealing with multiple screen sizes. With this feature, Eclipse could be close to perfection, and I guess nothing is perfect - that's why it remains unimplemented.

A very serious flaw though.
Comment 103 Andrey Loskutov CLA 2008-12-05 08:09:28 EST
(In reply to comment 89)
Just for the record: bug 245178 is one of corner cases why the word wrap must 
be supported: Eclipse on Linux does not allow to display/edit lines longer then 7710 characters. 

This happens not with "average Joe" files, but if you MUST edit your LONG text in Eclipse on Linux, then it is critical failure... So currently it's a showstopper for anyone who uses Eclipse on Linux for serious text processing...
Comment 104 Dani Megert CLA 2008-12-05 09:15:25 EST
>Eclipse on Linux does not allow to display/edit lines longer then 7710 
>characters. 
Not true. The bug you refer is against the Text and not the StyledText widget. And even if it is: did you test that when enabling SWT.WRAP the limit is gone?
Comment 105 Andrey Loskutov CLA 2008-12-05 09:53:02 EST
Created attachment 119623 [details]
Long lines broken on Linux

(In reply to comment #104)
> >Eclipse on Linux does not allow to display/edit lines longer then 7710 
> >characters. 
> Not true. The bug you refer is against the Text and not the StyledText widget.

Then even both widgets are not working... I see the same behavior with my own plain 3.4.2 Eclipse on GTK, so the bug is there.

> And even if it is: did you test that when enabling SWT.WRAP the limit is gone?

How can I test it if the Eclipse text (java) editor does NOT support word wrap yet? I have tested with gedit which shows exactly the same bad behavior as Eclipse (it is also a GTK+ based), and after enabling word wrapping there, it works fine. How gedit it does, I don't know.

Back to my customer's use case:

1) Customer tries to edit plain text file (change some words in a line).

2) The file contains more then 7xxx characters in this one line.

3) Customer can't change the line (actually he can't see it properly). Neither Eclipse's plain text nor C++ nor Java editor works.

4) Customer asks me for help.

5) I'm looking into Bugzilla and check if there is a bug known: ok, the bug 245178 was already there. This bug is talking about SWT limitation on GTK and also about GTK/display drivers issues. I assume that it doesn't matter WHICH widget I take, ALL of them would fail on GTK+ with large lines.

6) Because the bug 245178 seems to be GTK/display driver bug (not Eclipse), it seems that I can't help my customer immediately.

7) Because I'm still looking for a doable solution for my customer, I'm trying to push an alternative solution: change Eclipse to allow word wrapping. 

Then the initial customer's request has nothing to do with long lines: the customer does NOT want to see 7000+ characters in ONE line, his wants to CHANGE this line. This is currently not possible. Would the Eclipse allow us to switch the word-wrapping in editors, I would go to my customer and explain him which option/menu/button his should press to continue his job. That's it.
Comment 106 Marc Esher CLA 2008-12-05 11:17:10 EST
As an interim solution, I can tell you that the CFEclipse plugin for Eclipse does support line wrapping. There's a button it puts into the chrome that looks like your typical word wrap button. basically, you open your file, you click the button, it wraps your text.

it's not perfect, but I find it works in a pinch when I need word wrapping but don't want to drop into a different editor like textpad.

Obviously this wouldn't work for an in-field RCP app where you don't want the client adding plugins. you might however have a look at the rather simple code they used to get it done. Again.... it's not perfect by any means. but it works.
Comment 107 Eric J. Schwarzenbach CLA 2009-02-04 21:08:00 EST
Here's another example where the lack of it is really frustrating and pathetic:
the console window. This is something that occurs for me fairly often. I launch my app from within Eclipse (in my case using Tomcat) and among the output that scrolls by in the console is a nested exception stacktrace. The preceding error line displays exception messages through several nested exceptions (some belonging to my app, by some from the framework I'm using) and extends, oh, eight hundred some odd characters. To get to the message text I'm interested in I have to scroll horizontally the equivalent of several monitor lengths.

That is the lame and moderately annoying part. The really frustrating part comes when I attempt to select a prime bit of the message in order to Google on it or search my code for it or whatever. The line below this mega-line is very short and does not extend below the bit I'm selecting. So if my cursor finger strays just a little below the line I am trying to select, WHAM the window snaps back to column zero again completely screwing up my selection and forcing me to start all over again. Granted that this perverse mouse / scroll behavior is a part of the problem too, but it wouldn't come into play if there were a reasonable line wrap behavior.
Comment 108 Nils Kilden-Pedersen CLA 2009-02-04 21:34:39 EST
This enhancement has been open for 5 years now. They're never gonna do it. Just give up.
Comment 109 Gary Gregory CLA 2009-02-04 22:16:08 EST
Replying to #107: My solution to problems like these is copy to the clipboard and paste to Notepad or Notepad++.
Comment 110 Ahti Kitsik CLA 2009-02-05 06:18:12 EST
Actually this is rather interesting example.
For console window wrapping should be more doable than for editors.

I'll take a look, maybe there's a hack available similar to my current wordwrap plugin.
Comment 111 BenH CLA 2009-02-05 21:52:36 EST
I reported issue97767, which was marked as a duplicate of this in June 2005. 

However, from the discussion here, bug #97767 is NOT a duplicate, because what I asked for was different: the ability for the Editor to auto-insert newlines  into typed text on the fly.

My use case was entering multi-line Javadoc comments. Currently its absurdly painful to create nicely formatted Javadoc as you type in the Eclipse editor. 

I distinguish my issue from this one as my request seems to require significantly less change to the editor architecture & APIs to support.
Comment 112 Nils Kilden-Pedersen CLA 2009-03-18 09:48:08 EDT
The 6 year anniversary of this feature request is coming up soon. 
Let's celebrate :-)
Comment 113 Yolian Ignatov CLA 2009-03-18 18:14:06 EDT
Dani, or whoever owns and has authority to make a decision on this feature: what's the current status?

It is difficult not to think of responses like

> Sorry, but this won't make it into 3.x.
or
> Sorry, but we won't work on this.

as disrespectful to everyone who has an interest in getting this resolved and particularly to people who've taken the time to share comments and suggestions. It's hard to imagine that anyone could possibly benefit from the way this has been handled so far.

If a decision has been made to not provide support for word wrapping, now or ever, then the bug should be marked WON'T FIX. An explanation of why this is the case would not only be appreciated but considering the number of votes, the level of feelings expressed so far, and the reference-like-status Eclipse aspires to be, it would be necessary. It'd also be very helpful to suggest what people who feel dissatisfied with such decision could do about it, i.e. who could they turn to.

Thanks!
Comment 114 Andrey Loskutov CLA 2009-06-05 09:08:13 EDT
Any chance to see this bug on the 3.6 roadmap? It is not too late yet ;-)
Comment 115 Dani Megert CLA 2009-06-05 09:54:36 EDT
Comment 47 still holds. Unfortunately we do not have enough resources to work on this. However, it is not a WONTFIX because anyone who badly wants this feature can step forward and invest the required time to study the code and work on a patch.
Comment 116 Michael Spector CLA 2009-06-07 10:04:25 EDT
*** Bug 182861 has been marked as a duplicate of this bug. ***
Comment 117 Gareth Dart CLA 2009-06-25 05:26:21 EDT
I'm sure that all concerned are now starting to think that this bug sounds like a stuck record, however, word wrap is a very important component of any editor.  It's not a feature, or an enhancement, or a useful plugin - it is a basic *requirement*.

We're migrating from Zend 5.5 to Eclipse in my office at the moment, and we were all baffled when we could not find it.  When I found this bug report after a bit of digging, I was frankly amazed to see that a request for such a basic requirement has dragged on for so long.

I understand that a lot of hard work goes into Eclipse, and I really do appreciate it, and I also appreciate that this is not the simple issue that it appears to be prima facie.  However, this isn't going to go away and it really, seriously and imperatively does need sorting out.

If resources are the issue, maybe Zend might stump up some cash for this?  It's a bit ridiculous that their Eclipse-based IDE lacks word wrap - that's got to be hurting their market share when all their competitors support it.

Cheers and thanks for the continuing work on the rest of Eclipse.

G
Comment 118 Jeffrey Stevison CLA 2009-06-25 11:56:04 EDT
I submitted a ticket to Zend about this very "bug".  Their reply was basically even though they charge $400 for their IDE they have limited resources and have no plans or interest in fixing this problem and submitting it to the project.  They said that this feature would be in eclipse when the community felt the need for it to be there.
Comment 119 Tev Kaber CLA 2009-06-25 15:08:58 EDT
It's really sad that although this is the #3 most requested feature (by votes), the developers have basically said flat out that they won't address it.

It's especially shocking since I can't recall another editor that won't do soft text wrap.  Out of curiosity, I opened a terminal and fired up Vi - and *it* has soft text wrap!

With Zend Studio and Flex both switching from being stand-alone apps to Eclipse plugins, Eclipse is rapidly becoming the go-to app, yet it lacks this very basic feature.

As more Zend and Flex users are migrated over, we'll probably see more people who miss this feature.

Basically if you ask Zend or Adobe, they shrug and say "it's an Eclipse thing" and if you ask Eclipse, they shrug and say "too hard, not doing it."

So it's the users who end up with the short end of the stick.
Comment 120 amr CLA 2009-07-13 02:48:06 EDT
Hello;

Unbelievable that this very simple feature is taking seven years of discussions.
Come on guys, even Notepad provides this elementary function.


I dont think that it is very hard to do, I have been using virtual word wrap 
http://www.ahtik.com/eclipse-update/

for along time and it is perfect.

I want to say that it never conflict with anything like goto line and Debugging or anything else.

Eclipse people, can not you just use what the guy just created ?or even ship it by default with Eclipse?

Comment 121 Tev Kaber CLA 2009-07-13 07:58:31 EDT
(In reply to comment #120) 
> Unbelievable that this very simple feature is taking seven years of
> discussions.
> Come on guys, even Notepad provides this elementary function.

Yeah, crazy, isn't it?

> I dont think that it is very hard to do, I have been using virtual word wrap 
> http://www.ahtik.com/eclipse-update/
> for along time and it is perfect.

Good suggestion, but on that site, it says "Currently it is wrapping properly BUT will make line numbering, active line highlight etc rendering damaged."

Is that the case?  If so, doesn't sound like a good solution (for me, anyway), since when I am debugging code and see "error on line 125" I need the line numbering in Eclipse to be accurate... I shouldn't have to turn soft text wrap off, go to the line, then turn it on again... 

Two things really bug me about the whole text wrap thing:
1) pretty much every other editor in the universe has it,
2) companies are starting to use Eclipse builds instead of stand-alone editors.  Zend Studio and Adobe Flex Builder, both of which I use, have switched to Eclipse.  So now products that I am paying a lot of money for lack soft text wrap, and when I complain to Zend and Adobe about it, they say "oh, we can't do anything about that, it's an Eclipse thing."   And the Eclipse devs just say "too hard, not doing it."

Sigh...  It's a passing the buck that means no customer support from anyone.
Comment 122 amr CLA 2009-07-14 01:22:13 EDT
(In reply to comment #121)

> Good suggestion, but on that site, it says "Currently it is wrapping properly
> BUT will make line numbering, active line highlight etc rendering damaged."
> 
> Is that the case?  If so, doesn't sound like a good solution (for me, anyway),
> since when I am debugging code and see "error on line 125" I need the line
> numbering in Eclipse to be accurate... I shouldn't have to turn soft text wrap
> off, go to the line, then turn it on again... 
> 

I understand your point, me also a debug fan, and when using word wrap the debugging is going very well, also go to line function.
the only two thing I don't like;
1- every time you open a file you need to apply the wrapper on it, no global setting.
2- the line numbers may be not accurate regarding the display, but functionally it is working.


Is it not that a good start for Eclipse Dev people? they can just start using it and fix these two issue.

Waiting for good response from the Eclipse Dev Team
Comment 123 Channing Walton CLA 2009-07-14 04:26:02 EDT
(In reply to comment #115)
> Comment 47 still holds. Unfortunately we do not have enough resources to work
> on this. However, it is not a WONTFIX because anyone who badly wants this
> feature can step forward and invest the required time to study the code and
> work on a patch.
> 

I'm curious to know what it would take for this bug to become important enough to take people off new feature development to fix it?  The voting system clearly isn't sufficient given this request is number 3 - perhaps the voting system isn't used?

Its not realistic for individuals to invest the time to fix this given the complexity involved unless there was significant support from people that understand the code deeply. Perhaps if there was a commitment to provide that assistance above 'ask in newsgroups' then someone might consider it?
Comment 124 Ketan Padegaonkar CLA 2009-07-24 01:12:19 EDT
Ping...
Comment 125 Dani Megert CLA 2009-07-30 09:45:38 EDT
>Is it not that a good start for Eclipse Dev people? they can just start using
>it and fix these two issue.
Well, it's not just two issues and that's actually the hard part. If you want word wrap and accept several features not working, then you can write a very simply plug-in with a part listener that has this code:


	public void partOpened(IWorkbenchPartReference ref) {
		IWorkbenchPart part= ref.getPart(true);
		if (part instanceof ITextEditor) {
			Control control= (Control)((ITextEditor)part).getAdapter(Control.class);
			if (control instanceof StyledText)
				((StyledText)control).setWordWrap(true);
		}
	}

This will enable word wrap when the editor is opened.


>Perhaps if there was a commitment to provide that
>assistance above 'ask in newsgroups' then someone might consider it?
We can give that assistance but we won't be able to explain everything (if so we could do it ourselves). So, the initial commitment would have to come from an individual or company declaring to want to invest several weeks fulltime on this.
Comment 126 Ahti Kitsik CLA 2009-07-30 18:51:39 EDT
Companies who are interested in sponsoring word wrap implementation with some cash -- please contact me directly ahti@codehoop.com for more details. It would be all-or-nothing deal -- sponsorship would be collected only after feature gets into platform codebase.

I'd be happy to come up with a more complete solution if platform team is ready to introduce required API changes and we get enough interest from other companies too. I'm pretty familiar with the codebase and related problems (at least I was ~2 years ago).

Looking forward to active feedback! :)
Comment 127 Channing Walton CLA 2009-07-31 01:59:15 EDT
I'm still curious about why this bug isn't been given high priority over new features given the amount of interest? My understanding, perhaps incorrectly, is that features are driven by community demand/interest? 
Comment 128 Dani Megert CLA 2009-07-31 02:20:35 EDT
>I'd be happy to come up with a more complete solution if platform team is ready
>to introduce required API changes
API additions are no problem but we cannot change/break any API for the 3.x stream releases.

>I'm still curious about why this bug isn't been given high priority over new
>features given the amount of interest? My understanding, perhaps incorrectly,
>is that features are driven by community demand/interest? 
Driven yes, but of course those who fund the work and those who actually do the work also have to say at least something and obviously other things like performance, stability, bug fixing, new APIs, etc. - and for 3.6 Java 7 - are weighted higher than word wrap.
Comment 129 Nils Kilden-Pedersen CLA 2009-07-31 07:57:00 EDT
> API additions are no problem but we cannot 
> change/break any API for the 3.x stream releases.

Does that mean you'll commit to implementing this for 4.0?
Comment 130 Dani Megert CLA 2009-07-31 08:06:47 EDT
>Does that mean you'll commit to implementing this for 4.0?
Sure not. What makes you think so? I only said that a solution for 3.x cannot break API.
Comment 131 Nils Kilden-Pedersen CLA 2009-07-31 08:29:36 EDT
(In reply to comment #130)
> What makes you think so?

Nothing makes me "think so". It was a question. A hopeful question, quickly squashed. Again.

Comment 132 Ahti Kitsik CLA 2009-07-31 08:35:20 EDT
(In reply to comment #130)
> >Does that mean you'll commit to implementing this for 4.0?
> Sure not. What makes you think so? I only said that a solution for 3.x cannot
> break API.
> 

For 3.x it could be even possible to avoid breaking the API.

BUT -- with the reservation that word wrap is never enabled until methods that
are added to the API are propagated to all the existing code that needs to
access visual line numbers.

This way current API methods will always be providing physical line
information. 

Later at one point when plugin writers have upgraded their plugins to new API
additions for visual-line-number components then we can put word wrap
enablement into the UI. Until then new API will also return physical lines
because word wrap is never enabled. I hope my proposal was clear enough, if not
please ask.

It would not directly break the API but yes, it would definitely change current
API semantics a bit..

Would that make sense?
Comment 133 Andrey Loskutov CLA 2009-08-02 07:14:50 EDT
(In reply to comment #132)

> For 3.x it could be even possible to avoid breaking the API.

Can you please give some more hints about how you would like to change the API without break it?

> BUT -- with the reservation that word wrap is never enabled until methods that
> are added to the API are propagated to all the existing code that needs to
> access visual line numbers.
> 
> This way current API methods will always be providing physical line
> information. 
> 
> Later at one point when plugin writers have upgraded their plugins to new API
> additions for visual-line-number components then we can put word wrap
> enablement into the UI. Until then new API will also return physical lines
> because word wrap is never enabled. 
> I hope my proposal was clear enough, if not please ask.

It was not clear enough, sorry.

What do you think about such plan:

1) A new "extension" API for ILineTracker and related interfaces is added in 3.x release in org.eclipse.jface.text.* or similar place. This extension allows NEW code to enable and use word wrapping.

2) Old API/implementation remains 100% compatible for all editors who isn't aware of the word wrap => if word wrap is NOT enabled, everything should still work as before.

How the editor should signal that it is prepared for the word wrap has to be decided, and should be the part of the API proposal. For example:

- editor must return an adapter for one of the new API's interfaces
- editor contributor has to init editor somehow or implement some new interface
- a preference for the specific editor id is set to enable/disable word wrap

3) Eclipse.org based projects can decide to switch some/all their editors in 3.x depending on the complexity of the required chhanges. 

For example, default text editor/properties editor probably can be switched easily to the new API (no code folding, no breakpoints etc). This would GREATLY help everybody who *physically* can't edit plain text files with long lines (see comment 105 for the use case).

Java editor (which is the most complex use case) can be adopted later, by JDT team, etc. 

Same is for all 3rd party companies/developers: existing plugins should keep working, but if they have time & resources, then they can upgrade to the word wrap.

I'm wondering if we can make a summary of the current state of the discussion/current proposals and update this page:
http://wiki.eclipse.org/index.php/Word_Wrap_for_Text_Viewer_and_Editor

Comment 58 (summary of GSOC project state)
Comment 75 (more details about possible implementation)
Comment 105 (use case for a simple solution in the default text editor)
Comment 107 (use case for console views)

I'm also wondering if it NOW makes sense to include this proposal to the 3.6 plan? Because now the goal would be NOT to implement the word wrap for each and every existing editor in ONE step, but just provide a new extension API and the simpliest possible client implementation (for "org.eclipse.ui.DefaultTextEditor" editor contribution).
Comment 134 Dani Megert CLA 2009-08-03 03:24:35 EDT
>Can you please give some more hints about how you would like to change the API
>without break it?
See http://wiki.eclipse.org/Evolving_Java-based_APIs.

>but just provide a new extension API and the
>simpliest possible client implementation (for
>"org.eclipse.ui.DefaultTextEditor" editor contribution).
The problem is that already the AbstractTextEditor works on a source viewer and supports annotations and the text editor supports line numbers and a corresponding ruler. So, it basically requires most of the work to be done for the simple text editor to work. The only thing we could leave away is projection/folding in this case.
Comment 135 Gareth Dart CLA 2009-08-06 06:41:16 EDT
Here's a real world example of where the lack of wrapping is causing me a real problem.  Consider this snippet of PHP:
<pre>
		if(Bouncer::can('edit', $this->id)){

			echo "<a 
			style = 'background-image: url(../images/16/edit.png);' 
			class = 'editOption' 
			href = 'index.php?option=identity&amp;task=identity-edit-current-attribute&amp;type=password&amp;id=$this->id&amp;attid=".$this->password->getId()."'
			>Edit current password</a>";

			echo "<a 
			style = 'background-image: url(../images/16/add.png);' 
			class = 'editOption' 
			href = 'index.php?option=identity&amp;task=identity-add-attribute&amp;type=password
			&amp;id=$this->id'
			>Add new password</a>";		

		}
</pre>

This is a very simple if statement that checks if a user has privs on an object, and if so outputs a couple of links.  I include the if statement to demonstrate that properly formatted, and therefore readable, code takes up a lot of width.  Obviously there is further indentation created by the method this is in, etc.

The first link creates valid HTML, but is difficult for developers to read, understand or edit as the long URL disappears off the edge of the screen (on a 1280 monitor with PHP Explorer and Outline views given a reasonable amount of screen space - yes I could minimise them but I use the all the time, literally every few seconds).

The second link is readable, but produces W3C validation errors (newlines and whitespace inside an attribute definition), and my organisation has a commitment to produce only valid code.

I'm running up against issues like this several times a day, and it definitely has an impact on productivity.  I'm aware that I could write a wrapper function that creates links for me and strips out the whitespace, but surely my editor should make life easier for me, not necessitate more work?

Just one example.  I'm sure other people have more numerous and more serious ones.

G
Comment 136 amr CLA 2009-08-06 10:27:33 EDT
This is a true example, actually seeing the whole line wrapped on a block is much than scrolling.

when I review code made other developer, I need to look at the code as whole block to rapidly identify problems.....

(In reply to comment #135)
> Here's a real world example of where the lack of wrapping is causing me a real
> problem.  Consider this snippet of PHP:
> <pre>
>                 if(Bouncer::can('edit', $this->id)){
> 
>                         echo "<a 
>                         style = 'background-image: url(../images/16/edit.png);' 
>                         class = 'editOption' 
>                         href =
> 'index.php?option=identity&amp;task=identity-edit-current-attribute&amp;type=password&amp;id=$this->id&amp;attid=".$this->password->getId()."'
>                         >Edit current password</a>";
> 
>                         echo "<a 
>                         style = 'background-image: url(../images/16/add.png);' 
>                         class = 'editOption' 
>                         href =
> 'index.php?option=identity&amp;task=identity-add-attribute&amp;type=password
>                         &amp;id=$this->id'
>                         >Add new password</a>";         
> 
>                 }
> </pre>
> 
> This is a very simple if statement that checks if a user has privs on an
> object, and if so outputs a couple of links.  I include the if statement to
> demonstrate that properly formatted, and therefore readable, code takes up a
> lot of width.  Obviously there is further indentation created by the method
> this is in, etc.
> 
> The first link creates valid HTML, but is difficult for developers to read,
> understand or edit as the long URL disappears off the edge of the screen (on a
> 1280 monitor with PHP Explorer and Outline views given a reasonable amount of
> screen space - yes I could minimise them but I use the all the time, literally
> every few seconds).
> 
> The second link is readable, but produces W3C validation errors (newlines and
> whitespace inside an attribute definition), and my organisation has a
> commitment to produce only valid code.
> 
> I'm running up against issues like this several times a day, and it definitely
> has an impact on productivity.  I'm aware that I could write a wrapper function
> that creates links for me and strips out the whitespace, but surely my editor
> should make life easier for me, not necessitate more work?
> 
> Just one example.  I'm sure other people have more numerous and more serious
> ones.
> 
> G
> 

Comment 137 Piotr Krukowiecki CLA 2010-05-28 10:19:31 EDT
Excuse me for not reading whole 136 comments before asking, but is bug also appropriate for requesting simple "wrap selected text" shortcut?

I.e. I just want to be able to select several lines and click "wrap" and either:
- wrap all lines that are too long
- re-wrap all lines so they are as long as possible but not longer than the limit

Just tokenize the selected lines and move words to next/previous line. It should be quite simple.
Comment 138 Gary Gregory CLA 2010-05-28 12:00:17 EDT
You can do that by formatting the selected text. Your formatting rules will be applied to the selection.
Comment 139 Gary Gregory CLA 2010-05-28 12:01:34 EDT
(In reply to comment #138)
> You can do that by formatting the selected text. Your formatting rules will be
> applied to the selection.

Oops, please ignore my last comment, I was thinking of the Java editor.
Comment 140 Aaron Digulla CLA 2010-05-28 15:49:19 EDT
Not sure whether this helps but I've extracted the text editor component from SWT and pushed it into a Mercurial repository along with a Maven POM to build and run the tests. You can clone it at:

http://epen.hg.sourceforge.net/hgweb/epen/StyledText/

See the comment in the pom.xml for how to import the Eclipse 3.6 plugins into your Maven repository.
Comment 141 Till Riedel CLA 2010-06-01 06:46:53 EDT
(In reply to comment #99)

I can confirm that the interplay between version control and eclipse would profit from such feature. Please consider that in a team not all members might use eclipse (and you will have a hard time staying with it). For those users your commits will be a pain if they need to merge or want to understand your patches.
Especially on small patches people react extremely happy if you reformated the complete code, because you couldn't read it otherwise. In some projects (e.g. working on customer code) this is a showstopper.

Another drastic case is editing LateX with eclipse. Texlipse is one of the most powerful TeX IDEs on the market thanks to eclipse, but IMHO it suffers a lot from missing soft word wrap.
Comment 142 Mauro Condarelli CLA 2010-06-10 08:03:37 EDT
There is an Open Source Project in Sourceforge that implements this feature (among other things); it is called "EclipseColorer".

I had a brief look to http://colorer.sourceforge.net/eclipsecolorer/.
Installed and and tested it.
Word wrap seems to work properly, even if it is a rather basic implementation.

Obviously that editor does *much* more than just word-wrap, but some knowledgeable person might be able to extract the relevant parts, with permission from the developers.
Comment 143 Jean-Noel Rivasseau CLA 2010-11-15 06:52:59 EST
I looked at Colorer and this does not help at all, because this editor can only be used when other editors (such as the JDT / CDT) etc are not used. The whole point of Eclipse is to take advantage of these editors so...

My only hope is that this feature is at least considered for Eclipse 4.0 APIs (but it does not look it will). I don't care about any new features except this one which thousands of people have been waiting for years.
Comment 144 Aaron Digulla CLA 2010-11-15 09:57:26 EST
(In reply to comment #143)

> My only hope is that this feature is at least considered for Eclipse 4.0 APIs
> (but it does not look it will). I don't care about any new features except this
> one which thousands of people have been waiting for years.

I've forked the text editor for my own project and I can comment a bit on the obstacles which prevent this bug from being implemented.

StyledText uses little to no encapsulation for performance reasons.

Most other editors use a class to handle a gap buffer for the text so they don't need to copy text around as you insert new text. On top of that is a line structure.

The structure with the start offsets of lines isn't aware of the gab buffer. Advantage: You can replace the character buffer with something else. Disadvantage: Every time you insert a character, you need to recalculate all line offsets.

In StyledText, both structures are mixed. So if text is inserted, only the line offset of the current line needs to be updated. That's good. It becomes a major pain if you use search&replace on a text.

Styles are handled in a similar way.

Adding word wrap would merge another logical view on the text with these three. Mess^3 would become mess^4. At every point in the code, you would have to consider 16 cases instead of 9, so to speak.

My conclusion: Unless someone comes up with a complete rewrite of the editor infrastructure, that is at least as fast as the current one, this isn't going to happen.
Comment 145 Eric Tiffany CLA 2010-11-15 10:40:51 EST
(In reply to comment #144)

> My conclusion: Unless someone comes up with a complete rewrite of the editor
> infrastructure, that is at least as fast as the current one, this isn't going
> to happen.

Well, it's not a rewrite, but it's been written for, oh, 30 years: Emacs.  

Colors and text styles have all been added along the way, but the basic functions discussed here,

- soft wrapping long lines,
- hard wrapping to a particular arbitrary line length

Have been there forever and continue to work.  

If eclipse editors were implemented on top of Emacs, well, that would be nirvana. Luddites could even have vi mode.  And it would probably revive lisp.

There are probably licensing issues, but that is a tempest in a teapot - maybe we need an Eclipse tea party to save all open-source-software from legal stagnation, but I digress.
Comment 146 vali.system+eclipse CLA 2010-11-15 11:59:03 EST
> If eclipse editors were implemented on top of Emacs, well, that would be
nirvana

Some people idea of heaven is the hell of others :)
Comment 147 Gareth Dart CLA 2010-11-15 12:11:53 EST
I think a thank you to Aaron Digulla is in order for a lucid explanation of why this would be a difficult task to accomplish.

The relative difficulty of this task, though, doesn't change the fact that 152 people have voted for it. I can't find a way to list bugs by number of votes, but 152 seems like a solid sort of number and seems to indicate that the user base think this is pretty important.

I love using Eclipse, but lack of word wrap is a serious and bizarre omission in the one IDE to rule them all.

G
Comment 148 Silver Zachara CLA 2010-11-15 13:33:32 EST
(In reply to comment #147)
> I love using Eclipse, but lack of word wrap is a serious and bizarre omission in
> the one IDE to rule them all.
> 

Hi,

it's really a paradox, the best IDE in 21 century and doesn't support Word Wrap.
Comment 149 Jean-Noel Rivasseau CLA 2010-11-19 11:49:51 EST
Very well summarized.

> (In reply to comment #147)
> > I love using Eclipse, but lack of word wrap is a serious and bizarre omission in
> > the one IDE to rule them all.
> > 
> 
> Hi,
> 
> it's really a paradox, the best IDE in 21 century and doesn't support Word
> Wrap.
Comment 150 Missing name CLA 2010-12-08 03:24:06 EST
I would really like to see this implemented. Just to give my 2¢: I'd like soft word wrap, not indented, with wrapped lines not changing the numbering, so it goes

   10 This is a very long
      line number 10
   11 here is line number 11

with cursor movement like in notepad. For block-select, count the line as if it wasn't wrapped; making the block appear disjointed over wrapped lines. Heck, you can just implement the exact word-wrapping that's taking place in this edit box in your browser.
Comment 151 Charbel Gereige CLA 2010-12-20 07:45:05 EST
I have a vague memory of seeing somewhere (online) that this has been fixed in Eclipse and is now working without the need of 3rd parties plug-ins etc.
Am I right or was it just a dream? if this is correct can someone point me to how to do that.
Comment 152 Aaron Digulla CLA 2010-12-20 08:38:07 EST
(In reply to comment #151)
> I have a vague memory of seeing somewhere (online) that this has been fixed in
> Eclipse and is now working without the need of 3rd parties plug-ins etc.
> Am I right or was it just a dream? if this is correct can someone point me to
> how to do that.

There is an option for the editor to enable word wrap but it messes with other plug-ins (showing annotations in the border of the editor).
Comment 153 Charbel Gereige CLA 2010-12-20 10:26:41 EST
(In reply to comment #152)
> (In reply to comment #151)
> > I have a vague memory of seeing somewhere (online) that this has been fixed in
> > Eclipse and is now working without the need of 3rd parties plug-ins etc.
> > Am I right or was it just a dream? if this is correct can someone point me to
> > how to do that.
> 
> There is an option for the editor to enable word wrap but it messes with other
> plug-ins (showing annotations in the border of the editor).

can you please elaborate on the editor option? where can I find that option? is that a "hard"/"soft" wrap?
Comment 154 Aaron Digulla CLA 2010-12-20 11:03:40 EST
(In reply to comment #153)

> can you please elaborate on the editor option? where can I find that option? is
> that a "hard"/"soft" wrap?

See StyledText.setWordWrap() (http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.6/org.eclipse.swt.gtk.linux/x86_64/3.6.0/org/eclipse/swt/custom/StyledText.java#StyledText.setWordWrap%28boolean%29). 

It's a soft wrap.
Comment 155 Aaron Digulla CLA 2011-01-04 15:46:54 EST
To get this moving, here is a suggestion. When I write text editors with SWT, my main pain is to synchronize the editor model with my own model.

So say we have a spell checker. The spell checker is really orthogonal from any other thing that might style the text. What I want is to be able to add a "spelling layer" on top of the existing styles. The text editor should then move the styles in my layer as text is inserted/removed and notify me about the part that I need to update.

The editor already contains most of the code to update styles as the text changes but this code is off limits and can't be reused: The package is signed (so you can't add classes without recompiling all of SWT), the relevant code itself is package private (so you can't use it from outside the package).

I've started to refactor the whole beast. One thing that I did was to move all code that works on styles into a StyleRangeModel. That's actually pretty easy. Next step could be to introduce an interface so different or more complex models could be used. Like one which supports layers of styles (i.e. several StyleRangeModel models on top of each other which the editor will manage).

That would make it much more simple for plug-in developers to write complex editors. In fact most of the time, it should be sufficient to write a StyleRangeModel and leave everything else as it is. With this change, it should be more easy to get this bug here done.

So if you're interested in this, drop me a mail. Or visit http://epen.hg.sourceforge.net/hgweb/epen/ and check out the code. It's experimental at this time (so it's not really as polished as I'd like it to be) but it compiles and the editor works.
Comment 156 Ahti Kitsik CLA 2011-03-08 06:48:32 EST
Just FYI, I updated the word wrap plugin to have a keyboard shortcut for switching http://bit.ly/hP4KsY

From the use-case perspective this "hack" covers most of my needs for now.

But for sure, it adds no value to actually getting it fixed the right way (which might never happen due to the complexity vs [commercial] interest.


(In reply to comment #153)
> can you please elaborate on the editor option? where can I find that option? is
> that a "hard"/"soft" wrap?

Charbel,
It's a soft wrap.
This option is available only internally at the API level but you can use the plugin from http://ahtik.com/blog/projects/eclipse-word-wrap/ to turn this on-off from the right-click menu.
Comment 157 Remy Suen CLA 2011-03-08 14:27:56 EST
*** Bug 339272 has been marked as a duplicate of this bug. ***
Comment 158 Dmitry Katsubo CLA 2011-08-01 11:24:08 EDT
I have tried two XML editors, that support line wrapping (http://colorer.sourceforge.net/eclipsecolorer/index.html and http://www.oxygenxml.com/download_oxygenxml_editor.html#Eclipse) -- they both have the same problem when searching through the file(s) (Search → File) and then navigating through the matches (Ctrl+.): when the match is found in the line, which is span outside the viewport, the viewport is not scrolled to show the highlighted match (the highlighting itself works OK). In other words: the next/prev match will only scroll to needed line, but not the line offset. So for matches that fit the view everything is OK, for others you need to scroll manually (insane!). I hope Eclipse 4.0 will have line wrapping + correct navigation.
Comment 159 Dotan Cohen CLA 2011-08-25 10:37:58 EDT
I think that it is obvious that the wrapping being requested by the majority of voters is for the visual representation of the code in the Eclipse window (soft wrapping), not the changing of code in the source file (hard wrapping). I do not know of another IDE that does not support (soft) wrapping: everything from Notepad to VIM does.
Comment 160 Dimitris Kolovos CLA 2011-10-24 17:35:54 EDT
Since StyledText now natively supports word wrapping, (I may be under the false impression that) this can be fixed without any major changes.

The following method needs to be added to LineNumberRulerColumn

     Map<Integer, Integer> getLineMap(StyledText text, ILineRange visibleLines) {
          TreeMap<Integer, Integer> lineMap = new TreeMap<Integer, Integer>();
         
          int endLine = Math.min(visibleLines.getStartLine() + visibleLines.getNumberOfLines(), text.getLineCount() - 1);
         
          int firstVisibleLineY = text.getLocationAtOffset(text.getOffsetAtLine(visibleLines.getStartLine())).y;
          int lineHeight = text.getLineHeight();
         
          for (int i=visibleLines.getStartLine();i<=endLine;i++) {
               if (i == 0) lineMap.put(0, 0);
               else {
                    int lineY = text.getLocationAtOffset(text.getOffsetAtLine(i)).y;
                    lineMap.put(i, visibleLines.getStartLine() + ((lineY - firstVisibleLineY) / lineHeight));
               }
          }
         
          return lineMap;
     }

and it's void doPaint(GC gc, ILineRange visibleLines) method needs to be slightly modified as follows:

     void doPaint(GC gc, ILineRange visibleLines) {
          Display display= fCachedTextWidget.getDisplay();

          // draw diff info
          int y= -JFaceTextUtil.getHiddenTopLinePixels(fCachedTextWidget);

          int lastLine= end(visibleLines);
         
          Map<Integer, Integer> lineMap = getLineMap(fCachedTextWidget, visibleLines);
         
          for (int line= visibleLines.getStartLine(); line < lastLine; line++) {
               int widgetLine= JFaceTextUtil.modelLineToWidgetLine(fCachedTextViewer, line);
               if (widgetLine == -1)
                    continue;
              
               int lineHeight= fCachedTextWidget.getLineHeight(fCachedTextWidget.getOffsetAtLine(widgetLine));
               paintLine(line, y, lineHeight, gc, display);
              
               int distanceFromPrevious = 1;
               if (line < fCachedTextWidget.getLineCount() - 1) {
                    distanceFromPrevious = lineMap.get(line+1) - lineMap.get(line);
               }
              
               y += (lineHeight * distanceFromPrevious);
          }
     }


Also, in the AbstractDecoratedTextEditor class, the following line needs to be added:

viewer.getTextWidget().setWordWrap(true);

I'm not sure which would be the best place to add the line above but I've added it to the createSourceViewer method of my subclass.

I've tested this quite a bit and it seems that search, bookmarks and line numbers all work fine.
Comment 161 Dani Megert CLA 2011-10-27 08:25:27 EDT
(In reply to comment #160)
> Since StyledText now natively supports word wrapping, (I may be under the false
> impression that) this can be fixed without any major changes.

Word wrap in the widget is there since 2.0. Your code fixes the line number ruler in some way (no numbers for visual/wrapped lines) but other things like markers, changed text etc. will not appear at the correct logical/visible line but only at the top of each wrapped block. Also, other things like text navigation actions (home/end) won't work as expected until patched. See also comment 33 for an interesting starting point.

BTW: Please note that Platform Text runs against EE J2SE-1.4, hence we can e.g. not use generics in the code.
Comment 162 Gary D. Gregory CLA 2011-10-27 09:04:47 EDT
Curious: Why does any component still require Java 1.4?
Comment 163 Nitin Dahyabhai CLA 2011-10-27 10:37:31 EDT
(In reply to comment #162)
> Curious: Why does any component still require Java 1.4?

You're looking at it wrong.  It's not that it requires 1.4, it's that it doesn't require *more* than 1.4.  To make a bundle as reusable as possible, you keep its requirements as low as possible--including its execution environment.

http://wiki.eclipse.org/Execution_Environments
Comment 164 Gary D. Gregory CLA 2011-10-27 10:45:23 EDT
Thank you for the clarification. 

I am surprised. Do we really expect people to develop with the latest Eclipse code on Java 1.4? Yikes. I can understand that a some folks might cherry pick plugins for some specific apps but still. 

IMO, maintenance branches can stay older Java versions but not the latest and greatest. At work, we are talking about moving from Java 6 to 7 to solve IPv6 issues...
Comment 165 Dimitris Kolovos CLA 2011-11-10 17:50:30 EST
Dani,

First of all, many thanks for your response and for all your hard work on the platform.

(In reply to comment #161)
> Your code fixes the line number
> ruler in some way (no numbers for visual/wrapped lines) but other things like
> markers, changed text etc. will not appear at the correct logical/visible line
> but only at the top of each wrapped block. Also, other things like text
> navigation actions (home/end) won't work as expected until patched. 

Agreed; the patch suggested is far from perfect. However, I'd consider things such as markers, navigation actions etc. to be minor inconveniences compared to not having soft line-wrapping at all, which in my view is a major handicap when editing any kind of text-intensive document (e.g. TeX, WikiText, HTML etc) - and this is mildly put compared to previous comments.

> See also
> comment 33 for an interesting starting point.

Comment 33 is interesting indeed but it dates back to 2006 and little seems to have been done in this direction since then. Until we reach a more comprehensive solution I think it'd make sense to at least provide this sub-optimal solution as an option (as also suggested in previous comments). 

> 
> BTW: Please note that Platform Text runs against EE J2SE-1.4, hence we can e.g.
> not use generics in the code.

It should be trivial to rewrite the code above without generics I guess.

If you believe that the provided solution is unacceptable, please let me know and I'd be happy to at least suggest some changes which would make it easier for plugin developers to support this feature in their custom text-based editors.
Comment 166 Mauro Condarelli CLA 2011-12-11 07:02:00 EST
(In reply to comment #165)
> Dani,
...
> If you believe that the provided solution is unacceptable, please let me know
> and I'd be happy to at least suggest some changes which would make it easier
> for plugin developers to support this feature in their custom text-based
> editors.

Dimitris,
please do.

I tried to incorporate the above changes, as a starting point to add further fixes (e.g.: highlight current line), but this seems next to impossible unless I clone the whole org.eclipse.jface.text package due to access restriction (e.g.: doPaint() is package-local, fCachedTextWidget is private, ...).

I am willing to contribute back some code (the proposed fix for line numbers does not seem very efficient), but I think it would be better to contribute in the form of some extension, since I am not in position to propose a complete solution to be included in the standard widget.

This way we could encourage people to incrementally build to a complete solution for this VeryLongStandingBug.

My plan was to override a few methods in my AbstractDecoratedTextEditor
e.g.: createLineNumberRulerColumn() to instantiate a custom modified LineNumberChangeRulerColumn.
The first part is ok, but I cannot simply write a CustomLineNumberChangeRulerColumn extends LineNumberChangeRulerColumn and override what needed for the reasons explained above.

Is there some alternative to cloning whole packages (or, at least, classes)?
Doing so will be a big headache to maintain if and when new versions of org.eclipse.jface.text are released.
Comment 167 shumisha CLA 2012-10-15 05:17:39 EDT
Hi Folks,

10 months since last comment on this topic. I think most people have given up and stopped asking but I think that doesn't mean the need for that feature has vanished. Maybe a few Eclipse users have.

I had bumped into this problem before, but since I switched to Asciidoc for creating documentation, I had to stop using Eclipse for this tasK. An it does pains me a lot to have to switch to a simple text editor outside of Eclipse each time I write documentation. Have to switch between apps to cut and paste code sample, no unified search, etc.

If Eclipse can't have a simple plain text editor (Asciidoc is just text), is anyone aware of 3rd party plugins that could allow text editing? or is that just not possible because it wouldn't work with other Eclipse features such as search?

Thanks and regards
Comment 168 Charbel Gereige CLA 2012-10-15 05:30:41 EDT
http://ahtik.com/blog/2011/03/08/new-eclipse-word-wrap-plugin-adds-keyboard-shortcut/ is the best I know
it has (or had) some issues with line numbering - which is the main reason why this hasn't been done in eclipse itself - not yet at least.

I hope this helps
Comment 169 Gareth Dart CLA 2012-10-15 05:37:25 EDT
Just so the devs know that this is still on people's radar, I'd like to add my support to the sentiments just expressed.

"I think most people have given up and stopped asking"

**Precisely** - in fact, the lack of (reliable and supported) word wrap in any PHP IDE was one of the key reasons cited for moving our organisation's development focus away from PHP and towards .NET. Not the only reason, certainly, but one of the main ones.  I'm not saying this in order to make a fuss, but simply to illustrate that features like this feed into real decisions about which *technologies* to use, not just which IDE.

(Before this decision was made, I convinced my boss to splash for two Zend Studio licenses, but even that doesn't have decent soft word wrap.)

"but I think that doesn't mean the need for that feature has vanished."

One would hope not. I still hope to see this is a future release.

G
Comment 170 shumisha CLA 2012-10-15 05:45:59 EDT
@Charbel: thanks, yes I'm aware of Ahti's plugin, have it installed, but the line numbering discrepancies is a bit of a drag, when you have to match error messages displayed by the tool chain to the original file.

@Gareth: don't know when that decision was taken, but it appears a bit excessive, I'm sure there were other, most important ones. If that matters, PHPStorm has soft word wrapping, and I believe NetBeans as well.

Rgds
Comment 171 Gareth Dart CLA 2012-10-15 05:58:26 EDT
@shumisha You are correct, this was one of a number of factors contributing to that decision. Although you can find several PHP IDEs that do *some* of the things you want in a reliable fashion, there wasn't one that ticked all of the many boxes. I'd much rather work in PHP than .NET, but regrettably it wasn't my call to make.
Comment 172 Mauro Condarelli CLA 2012-10-15 06:36:51 EDT
IMHO problem is TextEditor is about to die due to shift to e4 makes obsolete the whole org.eclipse.ui.* package tree.
None seems willing to spend time on a dieing component.
Problem is we don't have any inkling on what comes next, if anything.

I am currently (and slowwwwly) rewriting/porting something equivalent to TextEditor using plain jface.
I am proceeding in a very convoluted way following my specific needs.
Line numbering works fine (with soft wrap) and I implemented several other things (including two different spell-checkers hunspell and LanguageTool), next-in-line is annotation rendering (squiggly line) which misbehaves with soft-wrap.

If someone is interested in my experiments they are available. If and when I will have something really usable I will release on SourceForge, but it will take a long time since I'm working on this in my Ample Spare Time.

If some knowledgeable guy from the inner circle of eclipse developers could give us some advance information on what will become of TextEditor and friends that would be very appreciated
Comment 173 Dani Megert CLA 2012-10-15 06:49:31 EDT
(In reply to comment #172)
> IMHO problem is TextEditor is about to die due to shift to e4 makes obsolete
> the whole org.eclipse.ui.* package tree.
... 
> If some knowledgeable guy from the inner circle of eclipse developers could
> give us some advance information on what will become of TextEditor and
> friends that would be very appreciated

e4 does not touch the textual editor framework i.e. it is not directly affected nor will it be replaced by something e4-ish in the near future.
Comment 174 Dotan Cohen CLA 2012-10-15 06:59:59 EDT
> 10 months since last comment on this topic. I think most people have given up
> and stopped asking but I think that doesn't mean the need for that feature has
> vanished. Maybe a few Eclipse users have.
>

As much as I appreciate the Eclipse devs and I don't want to appear condescending, the truth is that due to this and other little 'papercuts' I've just given up on Eclipse. I bit the bullet and I'm now using VIM for everything except Java, and Netbeans for Java.

Eclipse is a wonderful product, but it is so full of little issues that add up that it becomes very frustrating to use. I only mention this to encourage the devs to look at the small issues such as word wrap, and to not only focus on large new features. In other words, please take as much pride in Eclipse as we take in the software that we write.

Why have I not sent in a patch? To be honest, if there were only one or two small issues I might. But in the end, learning VIM is the path of less resistance. This word-wrap issue is but a symptom of a larger problem that I cannot address with a patch: the Eclipse development team demonstrates little pride in their software. I mean that as constructive criticism with the intention of letting the devs know how their work is perceived, not with the intention to deride anyone. Please accept the viewpoint and learn from it.
Comment 175 shumisha CLA 2012-10-15 07:18:06 EDT
The goal of my comment was only to revive the interest and awareness of the issue among people who can do something about it.

From the duration of that thread, and comments that were made, I don't think word wrap is a "small thing". It appears to require large changes, and has good chances to break many plugins, so that's no small thing to me.
I don't believe either that Eclipse community would have left this open if it was simple. Having a GSOC project not able to getting close to solving fully the issue tends to confirm that.

On the other hand, e4 not touching the editor is bad news to me, as I had thought this bug was left lingering because upcoming e4 would allow solving it.

Now it appears we're left with no solution on the radar, simply adding more technical debt on top of technical debt.
Comment 176 Amenel Voglozin CLA 2012-10-15 09:53:45 EDT
(In reply to comment #175)
> From the duration of that thread, and comments that were made, I don't think
> word wrap is a "small thing". 
Exactly. I think we won't find anyone who says line wrap (not "word wrap") isn't needed, even though they might not need it themselves.

> 
> Now it appears we're left with no solution on the radar, simply adding more
> technical debt on top of technical debt.
I would say "adding **potential** technical debt..."
But yes, line wrap is pretty much the only thing I can lament in Eclipse (up to and including Indigo – Juno was a slowness nightmare to me and I reverted to 3.7.2).
Comment 177 Robert Konigsberg CLA 2012-10-15 10:26:08 EDT
Dotan, although I'm not an Eclipse Dev, I read your post suggesting that the Eclipse Devs don't take pride in their work, and telling everyone how their lack of pride is perceived. Let me tell you how your post is perceived. It's short-sighted, rude, and wrong. The Eclipse Devs work damn hard, and are understaffed. Whose fault is this? It's not the Devs. The entire team does their best balancing priorities and a limited budget and developer base. But pride? How can you tell what pride these people take in their work?

A key when wondering if someone is being condescending is when they start by saying they don't want to appear condescending. "How can I insult someone without looking as if I'm insulting them?" Yeah, that didn't work either. I suggest that you worry a little less in the pride you take in software, and a little more in the way you cultivate professional relationships.

I don't know what world you live in that gets things done by slapping people in the face, but I suggest you try something else. Or stick with VIM, it seems to be working for you. But thanks for the slap in the face on the way out.
Comment 178 Dotan Cohen CLA 2012-10-15 10:41:45 EDT
> Dotan, although I'm not an Eclipse Dev, I read your post suggesting that the
> Eclipse Devs don't take pride in their work, and telling everyone how their
> lack of pride is perceived. Let me tell you how your post is perceived. It's
> short-sighted, rude, and wrong.

Thank you for your viewpoint Robert. The point that I was making is that "little issues" such as line wrapping add up and cause people to abandon software.



> I don't know what world you live in that gets things done by slapping people
> in the face, but I suggest you try something else.

In the world in which I live I don't sugar coat. I stopped using Eclipse. Perhaps the devs would like to know why. This bug is why.

I do appreciate that _you_ don't sugar coat either, and that you took the time to let me know how my wording is perceived. I accept your constructive criticism and I learn from it.
Comment 179 Gary D. Gregory CLA 2012-10-15 11:00:36 EDT
It is hard to believe I created this ticket in 2003 and it is still generating comments. 

Talking down to Eclipse developers will not achieve anything IMO. If I've learned one think working with other folks is that if you treat people like children, they will behave as such. Berating the current community for a design decision made a decade ago is futile.

I still use Eclipse today, 3.7.1 works well, 4.2.1 is not as snappy and that's too bad.

I find it hard to believe, ludicrous actually, that someone would drop Eclipse in favor of vi[m] over something as mundane as soft line-wraps. How do you do refactorings? How do you run unit tests in a package, in a classpath entry, or just the one method you care about? How do you debug? How do you configure compiler warnings? 

If someone told me, I'm dropping Eclipse in favor of IntelliJ or NetBeans because I like foo and bar better, then I'd say, cool, maybe I'll consider that too. But vim? To paraphrase, "Surely you're joking Mr. Cohen".
Comment 180 shumisha CLA 2012-10-15 11:06:12 EDT
Hi Gary,

just a day after Felix had the longest free fall, you probably now have the longest standing feature request in the open source world ;)

That said, I don't think comparing the respective merits of various editors and IDE will bring any benefit here.

At this stage, we're just at "helpwanted" I think.
Comment 181 Dotan Cohen CLA 2012-10-15 11:09:37 EDT
> To paraphrase, "Surely you're joking Mr. Cohen".

I'm not joking, and don't call me Shirli!

For Java I use Netbeans, I did mention that. For everything else VIM is terrific. It did take me a few weeks to gain proficiency, but that was time very well spent!:wq
Comment 182 Gareth Dart CLA 2012-10-15 11:15:54 EDT
I think it goes without saying that the vast majority of commenters on this thread really like Eclipse, appreciate the efforts of the devs and would like to see a cracking open-source IDE made into an *even more* cracking IDE by the addition of soft word wrap that preserves line numbers.

The suggestion that they don't take pride in their work is insulting and irrelevant.  We can't extrapolate the work ethic of an entire community of developers from one bug report - but perhaps Mr. Cohen has written a VIM plugin that allows him to do so?
Comment 183 Michel Parisien CLA 2012-10-15 11:40:20 EDT
I love that my contribution to this discussion will be the least constructive, but Felix did not have the longest free fall, he pulled his chute too early. He did however jump from the highest height and got to the highest height for a person in a weather balloon. He also came down the fastest, being the first human to break the sound barrier.
Comment 184 Robert CLA 2012-10-15 20:09:38 EDT
sorry for the Eclipse devs, but Cohan is right. Linebreaks is a very basic feature and even notepad on windows can do it. If you are working a lot with web projects it is a pain to scroll left/right through the code.

I had this ticked for years on my watch list and finally stopped using Eclipse and switched to Netbeans.
Comment 185 Gustavo Guillermo CLA 2012-10-19 17:30:31 EDT
This feature has to be introduced since the very beginning, but unfortunately, there are not other editor with such a very powerful kind of auto completion on Linux and for so many languages, so, I decided to keep using it since years even this feature is not working.

But, please someone take care of this, almost every editor has soft line wrap. I has to buy a bigger screen to have more text on front. This is not a solution.
Comment 186 Tchick CLA 2012-10-21 15:03:51 EDT
A workaround, that I use for the last years now, is to use the eclipse wiki markup editor for editing text files. This supports word wrap, and this is enough for me. Maybe this information could be of help to some of you.

What I didn't understand exactly is, why it's too hard to make the text editor use this feature, too, as it works for other plug-ins as the wiki markup for example. But I don't know anyting about the technical details here ...
Comment 187 shumisha CLA 2012-10-22 04:09:30 EDT
Hi Tchik

Thanks very much for the. Though I lost line numbering, using the wikiText editor at least allows editing documentation properly from inside Eclipse.
File search works fine, and that's all that matters to me at this point.
Going to seach and see if there might be some support for Asciidoc coming!
Comment 188 Mauro Condarelli CLA 2012-12-27 07:44:19 EST
IMHO problems come from fact StyledText itself still shows several bugs when used with WRAP style (e.g.: 281747).

I am slowly worming my way through writing a new "TextEditorWidget" which will support almost everything TextEditor has, but it relies only on SWT/Jface (in particular NO org.eclipse.ui.*).
Development is slow and a bit schizoid because I implement just what I need.

I have little knowledge about what is needed to get into incubation and standard release; if there's interest please advise me.

Current code correctly handles D&D, line numbers and Annotations; test environment adds several nice features like SpellChecker (JLanguageTool) Thesaurus (my java rewrite of MyThes; I use their data files) and multi-tab editor.

I did not tackle Action building yet.
Comment 189 Robert Konigsberg CLA 2012-12-29 20:24:05 EST
So how about this: Aptana Studio supports line wrap. So it's possible!
Comment 190 Eric Rizzo CLA 2012-12-29 20:52:31 EST
(In reply to comment #189)
> So how about this: Aptana Studio supports line wrap. So it's possible!

So someone should ask them (Aptana) to contribute their code back. 'Cause it's clear that without a community contribution this is not going to be implemented.
Comment 191 Amenel Voglozin CLA 2012-12-30 06:05:38 EST
(In reply to comment #190)
> 
> So someone should ask them (Aptana) to contribute their code back. 

I totally second that. But who should approach them? The Eclipse Foundation? or users?
Comment 192 Florian Weßling CLA 2013-02-06 07:19:28 EST
Hello :)

I managed to fix the line ruler to make it work together with the word wrap plug-in. The word wrap plug-in by ahtik does not work anymore with the latest Eclipse release, therefore I wrote a new one.

An instruction how to install the plug-in and the fix for the line ruler can be found on my project website: http://dev.cdhq.de/eclipse/word-wrap/

In general I created a new word wrap plug-in and fixed the line ruler rendering in the org.eclipse.jface.text plug-in.

I hope this will help many people and may be included in an official Eclipse release if there are no serious problems in combination with other plug-ins. ;-)

It is tested on Windows 7 and OS X 10.8.2 with Eclipse Juno 4.2.

Any feedback is appreciated! :-)
Comment 193 Gustavo Guillermo CLA 2013-02-06 10:12:00 EST
Created attachment 226635 [details]
The new word wrap plugin in the old 3.7

Is there any chance to get this plugin working with 3.7 instead of only with 4.2? I'm in production so I can't spend 1 or 2 weeks tuning a newest version of eclipse.
Comment 194 Florian Weßling CLA 2013-02-06 10:13:09 EST
Comment on attachment 226635 [details]
The new word wrap plugin in the old 3.7

Sure, please wait a few minutes. I will upload a 3.7 fix very soon. :)
Comment 196 Amenel Voglozin CLA 2013-02-06 12:01:41 EST
@Florian: Indigo SR2 doesn't find any update site at the address you gave. Same goes with removing the hash and with removing the "indigo" anchor altogether :-(
Comment 197 Florian Weßling CLA 2013-02-06 12:09:52 EST
(In reply to comment #196)
> @Florian: Indigo SR2 doesn't find any update site at the address you gave.
> Same goes with removing the hash and with removing the "indigo" anchor
> altogether :-(

Sorry, there is no update-site for the line wrapping fix. You have to copy the downloaded file manually to your plugin folder. I will see if it is possible to add an update site for the line wrapping fix aswell. :)
Comment 198 Gustavo Guillermo CLA 2013-02-06 12:49:34 EST
Just Awesome.!! Thanks for the fix for eclipse 3.7, I've tested with most plugin editors I have:

C# (Emonic) OK
Perl (Epic) OK
Shell (Shelled) OK
Java OK
PHP OK
Css OK
XML (Android) FAIL, can't toggle in editor view (no effect).

The folding icons does not get updated when you toggle Word Wrap, but if you never turn off again is just an eye candy fix. Perhaps to fire such event.

I propose the fix should be in the next version of eclipse.!!!

Many thanks to Florian Weßling.!!!
Comment 199 Florian Weßling CLA 2013-02-06 12:52:23 EST
(In reply to comment #198)

Nice, glad to hear! I will see whether I can get the Android XML editor to work with the fix. Do you mean the standard editor in the Android Development Tools (ADT)? :)
Comment 200 Gustavo Guillermo CLA 2013-02-06 13:00:42 EST
Is there any chance the plugin can be available for offline installing, instead only throw the update site?

JavaScript editor also tested OK!.
XML Outside Android FAIL.!

Also I recommend to check with bigger files. Eclipse is not good for such a real big files, but if it slows down considerably the editor, perhaps making an optimization in the paint functions could help.

At this point, checking with real big projects: and there is no any inconvenience, with many types of editors tested.!!!
Comment 201 Florian Weßling CLA 2013-02-06 13:04:36 EST
(In reply to comment #200)
Sure, no problem. I will upload a zip file with the files to be installed manually as quickly as possible. Then offline installation should be possible. ;)
Comment 202 Andrey Loskutov CLA 2013-02-06 17:41:05 EST
(In reply to comment #192)
[...]
> In general I created a new word wrap plug-in and fixed the line ruler
> rendering in the org.eclipse.jface.text plug-in.

Beside the patch binaries can you please provide the source patches for org.eclipse.jface.text plugin? I think it would be a good idea to attach here the source patches for two current stable heads (3.8.x and 4.2.x).
 
> I hope this will help many people and may be included in an official Eclipse
> release if there are no serious problems in combination with other plug-ins.

I would highly appreciate patched org.eclipse.jface.text 3.8.2 version and/or just a source patch for the latest stable 3.8.x branch version.

I haven't tried the patch/reviewed the code but I would *love* to see it in the official Eclipse git repository.
Comment 203 Florian Weßling CLA 2013-02-06 18:46:48 EST
I updated the project website: http://dev.cdhq.de/eclipse/word-wrap/

The installation is now easier because the word wrap plugin and the line number ruler fix can be downloaded from the same update site. Now there are also two separate update sites: One for Eclipse Indigo 3.7 and one for Eclipse Juno 4.2 :)

Only the TeXlipse patch has to be applied manually.

Okay, the next thing I do is to find out how to create these patches :)
Comment 204 GiUmaTo Mising name CLA 2013-02-07 06:53:50 EST
I've tested it on Juno 4.2.1, Windows 7 64 bit, online installation: it works great! Thanks for your work!
Comment 205 Florian Weßling CLA 2013-02-07 07:11:19 EST
(In reply to comment #204)
> I've tested it on Juno 4.2.1, Windows 7 64 bit, online installation: it
> works great! Thanks for your work!

That's great! You are welcome :)

(BTW a git patch is on the way. I will create one when I find time to do so. :) )
Comment 206 Lars Vogel CLA 2013-02-07 07:21:13 EST
@Florian: how to create a patch is described here: http://www.vogella.com/articles/Git/article.html#gitpatch
Comment 207 Florian Weßling CLA 2013-02-07 14:35:56 EST
Created attachment 226727 [details]
git patch for the master branch of eclipse.platform.text.git (Eclipse Juno 4.2)

This is the patch for the changes I made to the LineNumberRulerColumn.java in the org.eclipse.jface.text.source package. It fixes the line number ruler rendering to make it work with the word wrap plugin (http://dev.cdhq.de/eclipse/word-wrap/).
Comment 208 Gareth Dart CLA 2013-02-08 02:45:05 EST
Florian, you are a *hero*. Brilliant. Can confirm that the 3.7 plugin works great in Zend Studio (v9, build 20121008 running on Win 7 32bit, if you need to know). Thank you.
Comment 209 Charbel Gereige CLA 2013-02-08 04:48:37 EST
I tried it - through eclipse new software update -  in Juno, it's working nicely!
http://dev.cdhq.de/eclipse/updatesite/juno/

thanks a lot!

Basically all I had to do is right click in an open file and select "Toggle Word Wrap" (shortcut ctrl+alt+e)

Question, is there a possibility to have a system-wide option that gets persisted - similar to the option in Visual Studio. This way I don't have to always set this for every file I open every time I open eclipse? In essence I want eclipse to always (soft) word wrap all files all the time. Others may want to have the option on a per language (editor) basis - so maybe the option can go on the Editor preferences - in the preferences dialog. 

Anyway - thanks a lot for this!
Comment 210 Charbel Gereige CLA 2013-02-08 04:50:28 EST
I just noticed it was reported on 2003-03-27 15:06... almost 10 years anniversary!!
Comment 211 Jan Mutter CLA 2013-02-08 05:49:05 EST
Confirming that it works on Spring Tool Suite, Version: 3.1.0.RELEASE, Build Id: 201210061306

Using the Plugin for Eclipse Juno 4.2

Great! Great! Great! Thank you so much, Florian!
Comment 212 Florian Weßling CLA 2013-02-08 11:21:28 EST
I'm very happy that you like it and that it is working without problems! :)

Sure, I read something about the Eclipse Preference Store a few weeks ago. (Oh, a little bit of Googling brought me, of course, to another great tutorial by Lars Vogel ;) http://www.vogella.com/articles/Eclipse4Preferences/article.html)

But this plug-in is not the right place to do this. It is something workbench or editor related and should be handled in there (which makes the word wrap state globally as you suggested).

I think the preferences should offer an option to set the default state of word wrap in every editor that will be opened. But there should also be an option in every editor to turn it off. Toggling word wrap within one editor shouldn't toggle it in every editor, should it?
Comment 213 Vlad Sharanhovich CLA 2013-04-08 16:40:01 EDT
(In reply to comment #203)
> I updated the project website: http://dev.cdhq.de/eclipse/word-wrap/

The site server http://dev.cdhq.de seems to be down. Update site http://dev.cdhq.de/eclipse/updatesite/juno/ and project site http://dev.cdhq.de/eclipse/word-wrap/ are not accessible too of cause.
Comment 214 Florian Weßling CLA 2013-04-08 17:18:23 EDT
(In reply to comment #213)
> (In reply to comment #203)
> > I updated the project website: http://dev.cdhq.de/eclipse/word-wrap/
> 
> The site server http://dev.cdhq.de seems to be down. Update site
> http://dev.cdhq.de/eclipse/updatesite/juno/ and project site
> http://dev.cdhq.de/eclipse/word-wrap/ are not accessible too of cause.

Please check again. It is working flawlessly for me. Maybe there was a DNS issue or a temporary problem with the server.
Comment 215 Vlad Sharanhovich CLA 2013-04-08 17:59:47 EDT
Yes works for me again, my apologies for the false alarm.

(In reply to comment #214)
> (In reply to comment #213)
> > (In reply to comment #203)
> > > I updated the project website: http://dev.cdhq.de/eclipse/word-wrap/
> > 
> > The site server http://dev.cdhq.de seems to be down. Update site
> > http://dev.cdhq.de/eclipse/updatesite/juno/ and project site
> > http://dev.cdhq.de/eclipse/word-wrap/ are not accessible too of cause.
> 
> Please check again. It is working flawlessly for me. Maybe there was a DNS
> issue or a temporary problem with the server.
Comment 216 Gustavo Vargas CLA 2013-05-31 06:08:03 EDT
Thank you very much!

It works on Linux with eclipse Juno as well :) I had to do an eclipse -clean though. Otherwise every time I turned the wrap line function on it was automatically turned off again. eclipse -clean solved it.

Cheers!

(In reply to comment #192)
> Hello :)
> 
> I managed to fix the line ruler to make it work together with the word wrap
> plug-in. The word wrap plug-in by ahtik does not work anymore with the
> latest Eclipse release, therefore I wrote a new one.
> 
> An instruction how to install the plug-in and the fix for the line ruler can
> be found on my project website: http://dev.cdhq.de/eclipse/word-wrap/
> 
> In general I created a new word wrap plug-in and fixed the line ruler
> rendering in the org.eclipse.jface.text plug-in.
> 
> I hope this will help many people and may be included in an official Eclipse
> release if there are no serious problems in combination with other plug-ins.
> ;-)
> 
> It is tested on Windows 7 and OS X 10.8.2 with Eclipse Juno 4.2.
> 
> Any feedback is appreciated! :-)
Comment 217 Florian Weßling CLA 2013-05-31 12:25:00 EDT
Hi!

Thank you for sharing your experience with the -clean command. This usually happens when the new org.eclipse.jface.text plug-in is not loaded yet and the old one is still used instead. Nice to know that this command solves that problem. :)

Cheers! :)

(In reply to comment #216)
> Thank you very much!
> 
> It works on Linux with eclipse Juno as well :) I had to do an eclipse -clean
> though. Otherwise every time I turned the wrap line function on it was
> automatically turned off again. eclipse -clean solved it.
> 
> Cheers!
>
Comment 218 Lars Vogel CLA 2013-11-05 16:45:52 EST
Florian, could you convert your patch into a Gerrit review? Please see here for a step by step guide: http://www.vogella.com/articles/Gerrit/article.html#eclipsegerritcontribution
Comment 219 Jean-Noel Rivasseau CLA 2013-12-24 10:31:48 EST
Florian, the plugin is awesome but it does not seem to work, very unfortunately, with XML editors (in source mode). Ahtik plugin worked with those. Is it a known bug or limitation?
Comment 220 Jean-Noel Rivasseau CLA 2013-12-24 10:32:55 EST
Florian, the plugin is awesome but it does not seem to work, very unfortunately, with XML editors (in source mode). Ahtik plugin worked with those. Is it a known bug or limitation?

(Also, it would be perfect if I could assign a custom key shortcut to it...)
Comment 221 Lars Vogel CLA 2014-01-17 05:24:51 EST
(In reply to Florian Weßling from comment #217)

FYI - Gerrit has been enabled for platform.text
Comment 222 Florian Weßling CLA 2014-02-03 08:02:29 EST
(In reply to Jean-Noel Rivasseau from comment #220)
> Florian, the plugin is awesome but it does not seem to work, very
> unfortunately, with XML editors (in source mode). Ahtik plugin worked with
> those. Is it a known bug or limitation?
> 
> (Also, it would be perfect if I could assign a custom key shortcut to it...)

Please take a look at the version I've uploaded today (Updatesite: dev.cdhq.de/eclipse/updatesite/kepler). It now supports XML editors. :)
Comment 223 Florian Weßling CLA 2014-02-03 11:13:30 EST
(In reply to Lars Vogel from comment #218)

Patch successfully (I hope so ;) ) converted to Gerrit review: https://git.eclipse.org/r/21478/
Comment 224 Lars Vogel CLA 2014-08-05 05:25:32 EDT
(In reply to Florian Weßling from comment #223)
> (In reply to Lars Vogel from comment #218)
> 
> Patch successfully (I hope so ;) ) converted to Gerrit review:
> https://git.eclipse.org/r/21478/

Do you also have a patch for the word wrap functionality? https://git.eclipse.org/r/21478/ looks like it only fixes an issue with the line ruler if word wrap is active.
Comment 225 Florian Weßling CLA 2014-08-05 10:23:05 EDT
Not yet, but currently I'm taking a closer look where the word wrap function can be put. I guess org.eclipse.ui.editors.text is a good starting point. I'll post an update here when I have a working solution.
Comment 226 Florian Weßling CLA 2014-09-18 04:11:01 EDT
I wrote a patch but pushing it to ssh://fweling@git.eclipse.org:29418/platform/eclipse.platform.text.git is not possible (socket timeout). Is there something wrong with my configuration or is Gerrit currently not working?
Comment 227 Lars Vogel CLA 2014-09-18 04:32:10 EDT
(In reply to Florian Weßling from comment #226)
> I wrote a patch but pushing it to
> ssh://fweling@git.eclipse.org:29418/platform/eclipse.platform.text.git is
> not possible (socket timeout). Is there something wrong with my
> configuration or is Gerrit currently not working?

URL looks fine. Also I now tried for platform.ui with ssh://lvogel@git.eclipse.org:29418/platform/eclipse.platform.ui and Gerrit works fine for me.
Comment 228 Florian Weßling CLA 2014-09-18 04:46:59 EDT
It works now. Sorry, I guess the error was related my network connection.. Please take a look at the Gerrit review https://git.eclipse.org/r/#/c/33542/

I'm currently figuring out why Maven shows an error ;-)
Comment 229 shumisha CLA 2015-09-04 08:17:50 EDT
Hi all,

Almost 3 years after my last comment, which was already 9 years after this bug had been opened, no progress made it seems.

I have switched to Intelij Idea for about 15 month now, but miss Mylin and the quality og Git support in Eclipse. Came back checking on Eclipse Mars, installed and still no wrapping. Meaning no editing of my products documentation, painful html, etc

Maybe one day?

Cheers
Comment 230 Lars Vogel CLA 2015-09-04 09:03:29 EDT
(In reply to shumisha from comment #229)
> Hi all,

The Gerrit review needs an update. See https://git.eclipse.org/r/#/c/21478
Comment 231 shumisha CLA 2015-09-04 10:32:16 EDT
Hi Lars,

Thanks for your message. So it looks like there's actually quite a bit of work done, at least until last april. So I guess there's hope...
Comment 232 Eclipse Genie CLA 2015-09-11 04:22:20 EDT
New Gerrit change created: https://git.eclipse.org/r/55712
Comment 233 Andrey Loskutov CLA 2015-10-14 17:01:00 EDT
(In reply to Lars Vogel from comment #230)
> The Gerrit review needs an update. See https://git.eclipse.org/r/#/c/21478

I've fixed and updated both patches on latest HEAD state, I think they are now "ready-to-by-reviewed" by platform.text team.

Dani, Markus, can we continue with the working on the patches? I take the liberty to set the bug target to 4.6 M3.

It would be really nice to have it finally fixed and from the timing we just right with M3. This is one of the "most wanted" bugs/features in Eclipse.
Comment 234 Dani Megert CLA 2015-10-26 13:21:33 EDT
(In reply to Andrey Loskutov from comment #233)
> (In reply to Lars Vogel from comment #230)
> > The Gerrit review needs an update. See https://git.eclipse.org/r/#/c/21478
> 
> I've fixed and updated both patches on latest HEAD state, I think they are
> now "ready-to-by-reviewed" by platform.text team.
> 
> Dani, Markus, can we continue with the working on the patches? I take the
> liberty to set the bug target to 4.6 M3.
> 
> It would be really nice to have it finally fixed and from the timing we just
> right with M3. This is one of the "most wanted" bugs/features in Eclipse.

I'm very sorry for the delay. I really wanted to look into this for M3 but many other breakages required my immediate attention. I promise to have this top on my list for M4. Also, I will be at EclipseCon Europe and participate at the hackathon. If one of the authors of the Gerrit changes is there, we can finish this live.


I looked at the patch and the code looks pretty clean at a first glance. I did not yet perform a detailed code review but functional testing. Here some findings:

- When testing with the source of AbstractTextEditor I get exceptions [1].
  Test Case:
    1. open the file
    2. Ctrl+End
    3. set focus outside the editor
    4. set focus back to the edtior

- I'm not sure whether it is the new code, but switching to/from Block selection
  mode takes long (2-3s), while it is instantaneous in master. This is again
  using AbstractTextEditor as test source. Could be bug 168557.

- The preference page talks about "types" but uses extensions. We should use the
  newer concept which is content types.

- If we want to allow to configure the feature by content type then this should
  be something that other projects can extend (via extension point). If
  you agree to do that work, I'm fine tracking this in a separate bug and not let
  block this bug here.

- The preference page is missing mnemonics.

- The words "wrap" and "wrapping" are not used consistently. Please review this
  in all occurrences, including Javadoc.

- I don't like the 'Activate Word Wrap in All Open Editors' command. Besides that
  my experience from testing is that enabling/disabling word wrap is slow. This 
  could result in a UI freeze. Please remove it for now.

- Ctrl+Shift+W is already taken (Close All) and can't be used.

- I think we should also have a 'Toggle Word Wrap' icon in the toolbar.

- I guess at some point we will also have to allow to wrap at print margin and 
  not just at the view port end. But this is another request.

- Bug 408833 had to be reopened. This is something that has to be fixed before
  releasing this feature. Otherwise we will get negative feedback. I
  have targeted that bug for M4.


[1]
java.lang.IllegalArgumentException: Index out of bounds
	at org.eclipse.swt.SWT.error(SWT.java:4484)
	at org.eclipse.swt.SWT.error(SWT.java:4418)
	at org.eclipse.swt.SWT.error(SWT.java:4389)
	at org.eclipse.swt.custom.StyledText.getTextBounds(StyledText.java:5168)
	at org.eclipse.jface.text.CursorLinePainter.drawHighlightLine(CursorLinePainter.java:186)
	at org.eclipse.jface.text.CursorLinePainter.paint(CursorLinePainter.java:251)
...
Comment 235 Andrey Loskutov CLA 2015-10-26 19:18:25 EDT
(In reply to Dani Megert from comment #234)
> Also, I will be at EclipseCon Europe and participate
> at the hackathon. If one of the authors of the Gerrit changes is there, we
> can finish this live.

I *plan* to be there.

> - When testing with the source of AbstractTextEditor I get exceptions [1].
>   Test Case:
>     1. open the file
>     2. Ctrl+End
>     3. set focus outside the editor
>     4. set focus back to the edtior

I've reproduced this with opened "Collections" class in the editor and hope fixed this in the last patch.

> - I'm not sure whether it is the new code, but switching to/from Block
> selection
>   mode takes long (2-3s), while it is instantaneous in master. This is again
>   using AbstractTextEditor as test source. Could be bug 168557.

Is this when the word wrap was enabled? If not, I couldn't reproduce it. 
With word wrap enabled, switching from block mode back to the wrapped text for ~5000 lines needs a second or two, without word wrap enabled it is almost instant. 

> - The preference page talks about "types" but uses extensions. We should use
> the
>   newer concept which is content types.

I've changed preference page to talk about file extensions. I think we could start with this and change to content types in a follow up bug.

> - If we want to allow to configure the feature by content type then this
> should
>   be something that other projects can extend (via extension point). If
>   you agree to do that work, I'm fine tracking this in a separate bug and
> not let
>   block this bug here.

If we want this, yes, I can do this.

Honestly speaking I'm not sure how useful this entire page is, since I've never seen "word wrap by type" in any other editors and do not understand the need for "by type" configuration. 

I personally would keep it simple and just have on/off toggle. If someone wants exclusions etc we could either let the file extensions from the existing patch or add an enhancement request for later, but this is not mandatory feature for the first draft. I think most people simply want to have word wrap *everywhere* on request and *now*. Adding too many features just adds a risk that we will not have word wrap done in 4.6.

> - The preference page is missing mnemonics.

Added.

> - The words "wrap" and "wrapping" are not used consistently. Please review
> this in all occurrences, including Javadoc.

Hope to fixed all places.
 
> - I don't like the 'Activate Word Wrap in All Open Editors' command. Besides
> that
>   my experience from testing is that enabling/disabling word wrap is slow.
> This 
>   could result in a UI freeze. Please remove it for now.

The command is handy for testing the functionality and also for everyday use. I love alt+shift+A and so I would also love another binding too :-) 

Regarding "freeze" and "slow": what is your test case / acceptance criteria? I've tried with ~5000 lines big files and the word wrap switch needs ~1-2 seconds (I've tested on my Windows notebook, may be GTK/Mac is slower).
 
> - Ctrl+Shift+W is already taken (Close All) and can't be used.

Changed to Alt+Shift+Y, it was free on SDK installation. There are not much free key bindings :-(

> - I think we should also have a 'Toggle Word Wrap' icon in the toolbar.

This was my initial idea how it should be done before I've seen the patch with the command. I can / will add the button in a follow up bug. The biggest issue is the meaningful and nice icon.
Comment 236 Dani Megert CLA 2015-11-02 16:35:56 EST
(In reply to Andrey Loskutov from comment #235)

> > - I'm not sure whether it is the new code, but switching to/from Block
> > selection
> >   mode takes long (2-3s), while it is instantaneous in master. This is again
> >   using AbstractTextEditor as test source. Could be bug 168557.
> 
> Is this when the word wrap was enabled? If not, I couldn't reproduce it. 
> With word wrap enabled, switching from block mode back to the wrapped text
> for ~5000 lines needs a second or two, without word wrap enabled it is
> almost instant. 

Yes, with wrapping enabled.


> Honestly speaking I'm not sure how useful this entire page is.

I fully agree and removing it is fine for me. We don't have such special configuration for any other editor feature. Just having a checkbox on the 'Text Editors' preference page is fine.


> > - I don't like the 'Activate Word Wrap in All Open Editors' command. Besides
> > that
> >   my experience from testing is that enabling/disabling word wrap is slow.
> > This 
> >   could result in a UI freeze. Please remove it for now.
> 
> I love alt+shift+A and so I would also love another binding too :-)

I'm not sure what you try to say here. Alt+Shift+A only affects the active editor.


> Regarding "freeze" and "slow": what is your test case / acceptance criteria?
> I've tried with ~5000 lines big files and the word wrap switch needs ~1-2
> seconds (I've tested on my Windows notebook, may be GTK/Mac is slower).

And now assume you have 30 editors open. This would lead to a 1 minute freeze.

 
> > - I think we should also have a 'Toggle Word Wrap' icon in the toolbar.
> 
> This was my initial idea how it should be done before I've seen the patch
> with the command. I can / will add the button in a follow up bug. The
> biggest issue is the meaningful and nice icon.

k, fine with that.
Comment 237 Andrey Loskutov CLA 2015-11-02 17:14:04 EST
(In reply to Dani Megert from comment #236)
> (In reply to Andrey Loskutov from comment #235)
> > Honestly speaking I'm not sure how useful this entire page is.
> 
> I fully agree and removing it is fine for me. We don't have such special
> configuration for any other editor feature. Just having a checkbox on the
> 'Text Editors' preference page is fine.

OK, will add "[] Enable word wrap" after "Displayed tab width".
 
> > > - I don't like the 'Activate Word Wrap in All Open Editors' command. Besides
> > > that
> > >   my experience from testing is that enabling/disabling word wrap is slow.
> > > This 
> > >   could result in a UI freeze. Please remove it for now.
> > 
> > I love alt+shift+A and so I would also love another binding too :-)
> 
> I'm not sure what you try to say here. Alt+Shift+A only affects the active
> editor.

And so the Alt+Shift+Y will only toggle the wrapping in the current editor too, so I do not expect a huge impact on UI here.

> 
> > Regarding "freeze" and "slow": what is your test case / acceptance criteria?
> > I've tried with ~5000 lines big files and the word wrap switch needs ~1-2
> > seconds (I've tested on my Windows notebook, may be GTK/Mac is slower).
> 
> And now assume you have 30 editors open. This would lead to a 1 minute
> freeze.

As said, current command implementation only toggles the *current* editor state, same behavior as with the "Block selection mode". The only place where we do this for *all* editors is the global preference change.
Comment 238 Andrey Loskutov CLA 2015-11-02 18:09:07 EST
Created attachment 257691 [details]
New "Enable word wrap" preference option

Dani, I've understood that we were talking about different handlers. I've removed the "ToggleAll" handler now and the new WW preference page, instead left only "toggle WW in current editor" handler and added a simple option to the existing page, see attached picture and https://git.eclipse.org/r/#/c/33542/12.
Comment 239 Andrey Loskutov CLA 2015-11-03 11:44:32 EST
In the last patch set #13 introduces the toolbar button with the icon taken from https://git.eclipse.org/r/#/c/21787/. The patch is changed accordingly to use the action contribution and not the handler etc, just to follow same style as "toggle block mode" action contribution does.
Comment 240 Andrey Loskutov CLA 2015-11-03 13:52:09 EST
In the process of fixing last issues with the newly introduced toggle button I've stumbled on an odd UI behavior, and now asking myself: why the original patch which introduced the wrap API didn't switched the "block selection" mode off if "wrap" was enabled, BUT switches the "wrap" mode off if "block selection" is enabled?

This is totally inconsistent and feels like a bug from the user perspective. Those two modes must be mutually exclusive to each other - only one of them can be active at same time.

If nobody cries, I will go and change the first patch and make those two modes mutually exclusive. Anything else doesn't make sense for me.
Comment 241 Lars Vogel CLA 2015-11-03 14:34:34 EST
(In reply to Andrey Loskutov from comment #240)

> If nobody cries, I will go and change the first patch and make those two
> modes mutually exclusive. Anything else doesn't make sense for me.

Sounds good this change.
Comment 242 Eclipse Genie CLA 2015-11-03 18:19:46 EST
New Gerrit change created: https://git.eclipse.org/r/59615
Comment 243 Andrey Loskutov CLA 2015-11-04 01:25:16 EST
(In reply to Eclipse Genie from comment #242)
> New Gerrit change created: https://git.eclipse.org/r/59615

This new patch is required to fix vertical ruler NOT painting in the free area on the bottom of the ruler which is usually reserved for the horizontal scrollbar. If we enable word wrap, the horizontal scrollbar disappears and there is unmotivated gray area in the left bottom ruler part. With the patch, line numbers (or ruler background) are painted also in this area.
Comment 244 Andrey Loskutov CLA 2015-11-04 09:07:30 EST
The latest changes I've made were related to the unintended white space changes, smaller text and comment fixes and updated dates in the copyright headers.

Dani, now I think we have all 3 patches prepared for the final review, thanks for your time! I will stop pushing changes for now and wait for review comments.
Comment 245 Alex Poulton CLA 2015-11-05 14:09:17 EST
I was looking at different PHP IDEs and Eclipse looked great. Unfortunately I had to uninstall it almost immediately due to it missing ONE OF THE MOST BASIC FEATURES OF ANY TEXT EDITOR! This shouldn't be a patch or a plug-in where I have to worry about version compatibility and errors it should be a standard button in the toolbar.

I've heard all of the "Why would you want wordwrap? Your lines shouldn't be that long!" arguments. Here's why I need wordwrap:

1. I'm not always working on my own code, sometimes I'm just reading someone else's code to see what they're doing. I don't want to reformat the entire thing just to make it readable.
2. Editing PHP involves working with a lot of documents with HTML, wordwrap makes reading these much easier.
3. Sometimes I want to look at two pieces of code side by side. Wordwrap makes this much easier.
4. Screw you! I shouldn't have to explain why I want a feature that's been standard and basic in just about every text editor since the 1970s.

To summarize: Uninstalled.
Comment 246 Dani Megert CLA 2015-11-06 08:39:55 EST
(In reply to Andrey Loskutov from comment #244)
> The latest changes I've made were related to the unintended white space
> changes, smaller text and comment fixes and updated dates in the copyright
> headers.
> 
> Dani, now I think we have all 3 patches prepared for the final review,
> thanks for your time! I will stop pushing changes for now and wait for
> review comments.

Thanks Andrey!

I now did the full review of all three changes. The comments are all minor and should be easy to address.

One thing: How much is from you in the individual changes? I ask, because you added the other authors to the copyright notice at some places but never yours.
Comment 247 Andrey Loskutov CLA 2015-11-06 18:21:07 EST
(In reply to Dani Megert from comment #246)
> I now did the full review of all three changes. The comments are all minor
> and should be easy to address.

I've uploaded fixes for all 3 patches which should address all of the review comments.

> One thing: How much is from you in the individual changes? I ask, because
> you added the other authors to the copyright notice at some places but never
> yours.

In the first patch I've mainly cleaned up the new code, removed unnecessary changes etc, but also changed behavior of the "block vs wrap" API to mutually exclusive. In the second patch I've removed most of the changes: replaced the preference page changes with simpler one and changed handler to action + button. The third patch is entirely my own bugfix of the ruler layout. I've put now myself to the AbstractTextEditor and WordWrapToggleAction copyright headers, the rest I don't really care and AFAIK not more needed according to the recent discussions regarding copyright header updates.
Comment 248 Dani Megert CLA 2015-11-09 05:26:52 EST
Andrey, the Overview ruler (right side) is broken when word wrap is enabled. It no longer indicates the correct range for the annotations and draws cheese. This needs to be addressed before committing the changes.
Comment 249 Andrey Loskutov CLA 2015-11-09 06:51:55 EST
(In reply to Dani Megert from comment #248)
> Andrey, the Overview ruler (right side) is broken when word wrap is enabled.
> It no longer indicates the correct range for the annotations and draws
> cheese. This needs to be addressed before committing the changes.

Dani, do you have the bug number?
Comment 250 Dani Megert CLA 2015-11-09 08:18:47 EST
(In reply to Andrey Loskutov from comment #249)
> (In reply to Dani Megert from comment #248)
> > Andrey, the Overview ruler (right side) is broken when word wrap is enabled.
> > It no longer indicates the correct range for the annotations and draws
> > cheese. This needs to be addressed before committing the changes.
> 
> Dani, do you have the bug number?

No new bug. It's part of this work i.e. like the line number ruler, the overview ruler needs to be adjusted to support word wrap.
Comment 251 Andrey Loskutov CLA 2015-11-09 08:50:01 EST
(In reply to Dani Megert from comment #250)
> No new bug. It's part of this work i.e. like the line number ruler, the
> overview ruler needs to be adjusted to support word wrap.

OK, understood, I've updated the fist patch to include fix for AnnotationRulerColumn, see https://git.eclipse.org/r/#/c/21478/23. All other patches are rebased on top of this, so if you import https://git.eclipse.org/r/#/c/59615/5 you will have all patches updated in the workspace.

I've also quickly tested if the quick diff/git versions annotation are working with word wrap, and it seems they do (if I understood it right, they use LineNumberChangeRulerColumn which extends LineNumberRulerColumn and so should work). BTW do you know if we need to update (not used and kind of deprecated) ChangeRulerColumn? Also AbstractRulerColumn seems to be not deprecated but I do not see any use of it in platform.
Comment 252 Dani Megert CLA 2015-11-09 10:03:57 EST
(In reply to Andrey Loskutov from comment #251)
> (In reply to Dani Megert from comment #250)
> > No new bug. It's part of this work i.e. like the line number ruler, the
> > overview ruler needs to be adjusted to support word wrap.
> 
> OK, understood, I've updated the fist patch to include fix for
> AnnotationRulerColumn, see https://git.eclipse.org/r/#/c/21478/23. All other
> patches are rebased on top of this, so if you import
> https://git.eclipse.org/r/#/c/59615/5 you will have all patches updated in
> the workspace.

This does not work for me. I still see cheese while resizing the width of the editor are and the annotation is not fully drawn in the overview ruler.


> I've also quickly tested if the quick diff/git versions annotation are
> working with word wrap, and it seems they do (if I understood it right, they
> use LineNumberChangeRulerColumn which extends LineNumberRulerColumn and so
> should work). BTW do you know if we need to update (not used and kind of
> deprecated) ChangeRulerColumn? Also AbstractRulerColumn seems to be not
> deprecated but I do not see any use of it in platform.

We can deprecate ChangeRulerColumn.
Comment 253 Lars Vogel CLA 2015-11-09 10:52:06 EST
(In reply to Dani Megert from comment #252)
> We can deprecate ChangeRulerColumn.

Opened Bug 481735 for that.
Comment 254 Andrey Loskutov CLA 2015-11-09 11:02:30 EST
(In reply to Dani Megert from comment #252)
> This does not work for me. I still see cheese while resizing the width of
> the editor are and the annotation is not fully drawn in the overview ruler.

Dani, on which platform are you, and can you post a screenshot? On RHEL7 and pretty old GTK2 stack I do not see any cheese, or do not know what to do to get cheese :)
Comment 255 Dani Megert CLA 2015-11-09 11:16:58 EST
(In reply to Andrey Loskutov from comment #254)
> (In reply to Dani Megert from comment #252)
> > This does not work for me. I still see cheese while resizing the width of
> > the editor are and the annotation is not fully drawn in the overview ruler.
> 
> Dani, on which platform are you, and can you post a screenshot? On RHEL7 and
> pretty old GTK2 stack I do not see any cheese, or do not know what to do to
> get cheese :)

I'm on Windows 7. Simply having e.g. a bookmark and then changing the width of the editor area causes the overview ruler not to match the wrapped lines and/or cause cheese.
Comment 256 Andrey Loskutov CLA 2015-11-09 14:48:33 EST
(In reply to Dani Megert from comment #255)
> I'm on Windows 7. Simply having e.g. a bookmark and then changing the width
> of the editor area causes the overview ruler not to match the wrapped lines
> and/or cause cheese.

OK, see this now on Windows 10 too. I've updated the patches now with the fixed version of the OverviewRuler.
Comment 257 Dani Megert CLA 2015-11-10 03:18:38 EST
(In reply to Andrey Loskutov from comment #256)
> (In reply to Dani Megert from comment #255)
> > I'm on Windows 7. Simply having e.g. a bookmark and then changing the width
> > of the editor area causes the overview ruler not to match the wrapped lines
> > and/or cause cheese.
> 
> OK, see this now on Windows 10 too. I've updated the patches now with the
> fixed version of the OverviewRuler.

This fixes the cheese but it does not fix the correct drawing of the annotation in the overview ruler. The same applies to the annotation ruler on the left:

If we have this:

1 ABC DEF GHI JKL MNO PQR STU VWX YZ
2 ABC DEF GHI JKL MNO PQR STU VWX YZ
3 ABC DEF GHI JKL MNO PQR STU VWX YZ

and add a bookmark on VWX on line 2 and then shrink the editor when in word wrap, it will not show the bookmark on the wrapped line where VWX is (left and right).

If you agree to work on those (and possible other issues that we might find), then I suggest we commit the current changes and go forward from there.
Comment 258 Andrey Loskutov CLA 2015-11-10 04:29:51 EST
Created attachment 257843 [details]
RHEL7/GTK2 example with line wrapping and a bookmark

(In reply to Dani Megert from comment #257)
> This fixes the cheese but it does not fix the correct drawing of the
> annotation in the overview ruler. The same applies to the annotation ruler
> on the left:
> 
> If we have this:
> 
> 1 ABC DEF GHI JKL MNO PQR STU VWX YZ
> 2 ABC DEF GHI JKL MNO PQR STU VWX YZ
> 3 ABC DEF GHI JKL MNO PQR STU VWX YZ
> 
> and add a bookmark on VWX on line 2 and then shrink the editor when in word
> wrap, it will not show the bookmark on the wrapped line where VWX is (left
> and right).

Strange. I see it working fine now on GTK2/RHEL7 (attached picture), and I'm pretty sure it worked for me yesterday on Win 10 too. I will retest it on Win 10 this evening.

> If you agree to work on those (and possible other issues that we might
> find), then I suggest we commit the current changes and go forward from
> there.

Sure. There will be definitely other glitches as well, but I think the current state allows us to release it into the milestones builds for broader testing.
Comment 259 Dani Megert CLA 2015-11-10 05:00:46 EST
(In reply to Andrey Loskutov from comment #258)
> Created attachment 257843 [details]
> RHEL7/GTK2 example with line wrapping and a bookmark
> 
> (In reply to Dani Megert from comment #257)
> > This fixes the cheese but it does not fix the correct drawing of the
> > annotation in the overview ruler. The same applies to the annotation ruler
> > on the left:
> > 
> > If we have this:
> > 
> > 1 ABC DEF GHI JKL MNO PQR STU VWX YZ
> > 2 ABC DEF GHI JKL MNO PQR STU VWX YZ
> > 3 ABC DEF GHI JKL MNO PQR STU VWX YZ
> > 
> > and add a bookmark on VWX on line 2 and then shrink the editor when in word
> > wrap, it will not show the bookmark on the wrapped line where VWX is (left
> > and right).
> 
> Strange. I see it working fine now on GTK2/RHEL7 (attached picture),

If you look at your picture you can see that the bookmark icon on the left is not on the wrapped line where VWX is ;-).

Note: You need to create the bookmark via Edit > Add Bookmark...
Comment 263 Dani Megert CLA 2015-11-10 05:13:44 EST
Thanks everyone involved here!

I've committed the changes and opened bug 481818 and bug 481819 to track the ruler issues.
Comment 264 Markus Keller CLA 2015-11-11 11:32:57 EST
Properly formatted new code and fixed typo: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=6f1ed70f6ffa1db02ab73e9bc2c1c071f2c549ac
Comment 265 Eclipse Genie CLA 2015-12-04 08:11:26 EST
New Gerrit change created: https://git.eclipse.org/r/61972
Comment 267 Matthias Becker CLA 2016-01-12 11:10:29 EST
Today I tested the new word wrap feature in eclipse on my MacBook and found some strange bugs in it when navigating with the keyboard's curser keys.
See my attaced video.
- At 00:03 you see that is hit the "down key" multiple times but the cursor does not longer move once it arrives a wrapped line.
- Moving the cursor with "alt+right" moves the cursor correctly to the end of the wrapped line (at 00:07)
- When moving the cursor up (at 00:16) in the wrapped line the behaviour is also wrong as every second line is skipped

On windows everthing is fine. So this seems to be Mac-specific. Don't knwo how it's on linux.
Comment 268 Matthias Becker CLA 2016-01-12 11:16:39 EST
Created attachment 259132 [details]
Screencast that shows the wrong behaviour on Mac
Comment 269 Matthias Becker CLA 2016-01-12 11:19:32 EST
How can I re-open this bug report?
Comment 270 Eric Rizzo CLA 2016-01-12 11:37:25 EST
(In reply to Matthias Becker from comment #269)
> How can I re-open this bug report?

I think the appropriate action is to open a new bug report, then edit the Depends On list for that new one to include this one.
Comment 271 Dani Megert CLA 2016-01-12 11:51:47 EST
(In reply to Eric Rizzo from comment #270)
> (In reply to Matthias Becker from comment #269)
> > How can I re-open this bug report?
> 
> I think the appropriate action is to open a new bug report

Correct.
Comment 272 Sergey Prigogin CLA 2016-05-06 23:04:13 EDT
Should the "Toggle Word Wrap" command be exposed in a menu somewhere? Currently it is very hard to discover.
Comment 273 Dani Megert CLA 2016-05-10 11:42:50 EDT
(In reply to Sergey Prigogin from comment #272)
> Should the "Toggle Word Wrap" command be exposed in a menu somewhere?
> Currently it is very hard to discover.

Mmh. What you are saying is that the global toolbar button is harder to find than some item buried in some menu. I disagree with that.

Having said that, a general UI guideline says that all actions should be reachable via main menus. We have others, like 'Show Whitespace Characters', which don't follow that pattern. If this is important to you, please file a new bug to provide menu items for those editor actions.
Comment 274 Sergey Prigogin CLA 2016-05-10 13:46:43 EDT
(In reply to Dani Megert from comment #273)
> Mmh. What you are saying is that the global toolbar button is harder to find
> than some item buried in some menu. I disagree with that.

I didn't mean to say that, but, in fact, I didn't know about the toolbar button until having read this comment ;-)

Filed bug 493377.
Comment 275 Lars Vogel CLA 2016-05-10 13:58:12 EDT
(In reply to Sergey Prigogin from comment #274)
> (In reply to Dani Megert from comment #273)
> > Mmh. What you are saying is that the global toolbar button is harder to find
> > than some item buried in some menu. I disagree with that.
> 
> I didn't mean to say that, but, in fact, I didn't know about the toolbar
> button until having read this comment ;-)
> 
> Filed bug 493377.

We have a toolbar button? Nice, I always trigger word wrap via Quick Access.