>The Number One Perma-Bug on Eclipse

>…seems to be the lack of Word Wrapping support in the eclipse editor.

Well, for those that really need it, there is a plugin that shows that it can be done, but it needs some love.

AhtiK has developed a plugin that implements a Virtual Word Wrap. However it appears that this development has stopped. I would love to see the Platform team host the development in an incubator or really try to incorporate AhtiK’s work in e4.

Somebody has started the work…can the community pick it up and finish it? So here is my challenge to the community. Somebody create a Sourceforge or GoogleCode project, work with AhtiK to complete it, and then submit the contribution back to eclipse. Platform if somebody builds it will you accept it? As Dave E. Jones from Apache has said, collaboration is a two way street. Somebody has to be the first to step up to the plate.

Advertisements
This entry was posted in eclipse. Bookmark the permalink.

3 Responses to >The Number One Perma-Bug on Eclipse

  1. Heath says:

    >The column annotations are what make this bug particularly hard. The column annotations assume that word wrapping doesn't happen. Further, all of the jface text apis assume no word wrapping. This is a problem that may have to wait until we can break API in e4.The plugin you mentioned doesn't really do anything. He simply sets wordwrap to true in the underlying styled text. That doesn't even begin to scratch the surface of the issues that have to be dealt with.

  2. David Carver says:

    >@Heath Sure it may not do it elegantly, but it's a start. Also it's so much easier to come up with reasons it is hard to do than it is to actually jump in and do it. Reach out to the community, put an olive branch out.Ahtik was a google summer of code student, and he even documented some of the issues you emphasise on the eclipse wiki.http://wiki.eclipse.org/Word_Wrap_for_Text_Viewer_and_EditorLet's stop coming up with why it's difficult. Role up our collective sleeves and address the design flaws that prevent this from happening.

  3. AhtiK says:

    >Implementation itself would be perfectly doable and feasible. Not too simple but doable.BUT.. unfortunately one huge BUT is the way it breaks current API.The thing is that there are so many plugins (@eclipse.org and "3rd party") that use line number information. Some of them definitely need "visual" line numbers, others "physical/file" numbers.So without asking all of them to upgrade to the new API we can determine proper number to return only using extreme hacks like peeking stacktrace to find who is calling line number API etc.I've been talking to the Platform guys and breaking API so that current API would be only for physical lines and add a new API for visual is breaking too much stuff.But I've been keeping my thoughts around it and will be happy to continue as someone provides some new insights how this can be done. Very likely the initial implementation of next phase would be still hosted outside eclipse.org by patching classes etc because implementation would not meet the API stability and performance requirements.I'd be more than happy to hear ideas how this can be accomplished without breaking too much and not looking at the stacktrace.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s