...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.
The Number One Perma-Bug on Eclipse
Posted by David Carver
in Thursday, June 25, 2009
under:
eclipse
About Me
- David Carver
- My technical interests include XML, agile development, open source projects, and improving business to business standards development. At Eclipse.org I serve on the Architecture Council, and I'm a committer on the WTP Source Editing project focusing on XPath 2.0, XSLT, XML, and DTD development. I also help with the WTP Incubator VEX, XQuery, and RelaxNG development. View my linkedin profile.
Intellectual Cramps by David Carver is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Based on a work at intellectualcramps.blogspot.com.
Subscribe
Posts
Comments
Followers
Archives
Categories
- agile (64)
- agora (1)
- ant (2)
- bliteotw (2)
- bugday (2)
- build (29)
- cms (1)
- css (1)
- dita (12)
- docbook (25)
- docman (1)
- documentation (16)
- dr horrible (1)
- dvcs (2)
- e4 (1)
- eclipse (357)
- eclipsecon (1)
- encryption (1)
- galileo (1)
- git (1)
- home theater (1)
- hudson (1)
- java (1)
- joomla (3)
- linux (2)
- mantis (5)
- mono (1)
- mylyn (6)
- netflix (1)
- open source (10)
- osgi (3)
- pde (4)
- pdt (1)
- performance (3)
- php (5)
- refactoring (23)
- referring (1)
- relaxng (3)
- release engineering (25)
- reviews (1)
- schematron (1)
- scrum (6)
- security (3)
- silverlight (1)
- soccer (1)
- standards (32)
- standards. (2)
- summer of code (2)
- testing (40)
- testing. (1)
- ubuntu (2)
- web services (3)
- wiki (1)
- wsdl (1)
- wsi (1)
- xforms (2)
- xml (224)
- xpath (25)
- xquery (14)
- xsd (1)
- xsl (50)
- xslt (45)
- xtext (3)
- year end review (1)
- zombies (1)
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.
@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_Editor
Let's stop coming up with why it's difficult. Role up our collective sleeves and address the design flaws that prevent this from happening.
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.